Luca Clementi <[EMAIL PROTECTED]> writes:
> What do you mean with th standard input converter, you mean casting that
> string into a date with the default locate format. This won't work,
> because the machine where the DB is running is set to en.US, so it won't
> be able to parse that date. That
Tom Lane wrote:
Luca Clementi <[EMAIL PROTECTED]> writes:
I found the problem!!
to_timestamp(start_time, 'M DD, HH12:MI:SS')
in the formatting string I have two spaces, while in the original there
is only one:
1 28, 2008 12:23:19 �後
So if I use: 'M DD, HH12:MI:SS' as a formattin
Luca Clementi <[EMAIL PROTECTED]> writes:
> I found the problem!!
> to_timestamp(start_time, 'M DD, HH12:MI:SS')
> in the formatting string I have two spaces, while in the original there
> is only one:
> 1 28, 2008 12:23:19 åå¾
> So if I use: 'M DD, HH12:MI:SS' as a formatting strin
Tom Lane wrote:
Luca Clementi <[EMAIL PROTECTED]> writes:
It seems that the to_timestamp does not work properly in this case,
when it comes to parsing the hours.
to_timestamp() is not very robust if the input doesn't exactly match
what it expects for the format string. I'm not sure if that's
On Jan 30, 2008, at 19:26 , Tom Lane wrote:
(BTW, there is definitely 0 hope of recognizing a timezone name that's
written in Chinese characters, unless maybe you fool around with the
timezone-abbreviations configuration file.)
Just FYI, the characters in the original email are the equivalent
Luca Clementi <[EMAIL PROTECTED]> writes:
> It seems that the to_timestamp does not work properly in this case,
> when it comes to parsing the hours.
to_timestamp() is not very robust if the input doesn't exactly match
what it expects for the format string. I'm not sure if that's the
issue here,
