I think using the same time zone as the server is the only way to go:
Kris has proposed a patch which would set the servers time zone to
the JVM when the connection is started
This can still be broken if someone were to change the default
timezone after the connection was initiated.
If we do the reverse and save the servers timezone for the purposes
of creating the timestamp object we don't run into this problem, even
if someone were to issue a set timezone='newtimezone' we will still
get the notice and can update the
stored server timezone for the connection.
Dave
On 20-Jul-05, at 3:50 PM, Kris Jurka wrote:
>
>
> On Wed, 20 Jul 2005, John R Pierce wrote:
>
>
>> as we discovered the hard way, named timezones are a BAD IDEA.
>> We had some
>> stuff in java + jdbc + postgres that used a timezone, when it was
>> brought up in
>> Singapore, their local timezone memnonic wasn't recognized by
>> postgres, and
>> when it was brought up in China, CST was misinterpretted as
>> Central Standard
>> Time rather than China Standard Time (about 12 hours off)
>>
>>
>
> No, this indicates that *abbreviated* timezones are a bad idea, not
> named
> timezones.
>
> Kris Jurka
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
>