From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Postgres-Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: surprising to_timestamp behavior |
Date: | 2013-10-29 17:35:20 |
Message-ID: | CA+TgmobE0DoqF8W7=AmSiiJMfDWg5LMZhE0TgG+cOEJ-JF=uug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, Oct 29, 2013 at 12:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It turns out that when you use the to_timestamp function, a space in
>> the format mask can result in skipping any character at all, even a
>> digit, in the input string. Consider this example, where 10 hours are
>> lost:
>
>> rhaas=# select to_timestamp('2013-10-29 10:47:18', 'YYYY-MM-DD HH24:MI:SS');
>> to_timestamp
>> ------------------------
>> 2013-10-29 00:47:18-04
>> (1 row)
>
> And that's a bug why? The format says to ignore two characters before the
> hours field. I think you're proposing to remove important functionality.
>
> To refine the point a bit, it's absolutely stupid to be using to_timestamp
> at all for sane input data like this example. Just cast the string to
> timestamp(tz), and the standard datatype input function will do a better
> job than to_timestamp ever would. The point of to_timestamp, IMNSHO,
> is to extract data successfully from weirdly formatted input; which might
> well include cases where there are stray digits you don't want taken as
> data. So I'm not on board with proposals to "fix" cases like this by
> making the format string's meaning squishier.
Well, you're the second person to react that way to this proposal, but
the current behavior seems mighty odd to me - even odder, now that I
realize that we'll happily match '"cat'" to 'dog'. I just work here,
though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | joshuadburns | 2013-10-30 00:07:37 | BUG #8568: PLPGSQL Documentation For CASE Is incorrect |
Previous Message | Tom Lane | 2013-10-29 16:03:13 | Re: surprising to_timestamp behavior |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-10-29 18:44:26 | Re: Fast insertion indexes: why no developments |
Previous Message | Jeff Janes | 2013-10-29 17:15:14 | Re: Fast insertion indexes: why no developments |