On 06/01/2014 11:42 AM, David Wall wrote:
>
> On 6/1/2014 9:05 AM, Adrian Klaver wrote:
>> The JDBC code above, if I am following correctly, is picking up a
>> default timezone of 'PST' and then in the first if returning that as
>> the tz value to SET TimeZone in the startup packet.
>>
>> Two things.
>>
>> 1) Where is it getting PST from ?
>>
>> 2) Should the driver even be returning an abbreviation given that
>> Postgres will not accept it as a TimeZone value?
>>
>
>
> Thanks for the extra help, Adrian.
>
> It led me to investigate the 35 webapps we deploy on Tomcat and I found
> 2 rogue apps that set their timezone to "PST". Once I fixed these two,
> all is working great again.
>
> I guess there's no bug, per se, except in our configuration. Once we
> changed it to PST8PDT, all was good again.
Not so much a bug as a misplaced error. Given that TimeZone does not
accept abbreviations, it would seem that JDBC code should throw an
exception at that point. It would not change the end result, but make it
easier to determine where the error is occurring. In the long run it may
be moot though, because of this:
http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html
Three-letter time zone IDs
For compatibility with JDK 1.1.x, some other three-letter time zone IDs
(such as "PST", "CTT", "AST") are also supported. However, their use is
deprecated because the same abbreviation is often used for multiple time
zones (for example, "CST" could be U.S. "Central Standard Time" and
"China Standard Time"), and the Java platform can then only recognize
one of them.
>
> Thanks,
> David
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
