PostgreSQL JDBC - Re: Java's set of timezone names

Author

Re: Java's set of timezone names

Vadim Nasardinov

2005-07-20, 8:24 pm

On Wednesday 20 July 2005 14:57, Dave Cramer wrote:
> On my Mac my java timezone was set to Canada/Montreal which was
> broken (did not use DST ) and the server certainly doesn't
> understand it.

Out of curiosity, do you remember which JDK had this timezone?
Sun's JDK on Linux doesn't have it:

| $ find /usr/local/j2sdk1.4.2_08/jre/lib/zi/ -name Montreal
| /usr/local/j2sdk1.4.2_08/jre/lib/zi/America/Montreal

It only has America/Montreal, which PostgreSQL should grok just fine,
AFAICT:

| $ find /usr/share/zoneinfo/ -name Montreal
| /usr/share/zoneinfo/right/America/Montreal
| /usr/share/zoneinfo/posix/America/Montreal
| /usr/share/zoneinfo/America/Montreal

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Dave Cramer

2005-07-20, 8:24 pm

Vadim,

Actually you are correct, it is America/Montreal and now that I
switched it back it actually has useDaylight=true... very strange.

I think as John pointed out though there are some issues with using
named TimeZones.

Is there a way to get the servers timezone info from the server ?

Dave
On 20-Jul-05, at 3:10 PM, Vadim Nasardinov wrote:

> On Wednesday 20 July 2005 14:57, Dave Cramer wrote:
>
>
> Out of curiosity, do you remember which JDK had this timezone?
> Sun's JDK on Linux doesn't have it:
>
> | $ find /usr/local/j2sdk1.4.2_08/jre/lib/zi/ -name Montreal
> | /usr/local/j2sdk1.4.2_08/jre/lib/zi/America/Montreal
>
> It only has America/Montreal, which PostgreSQL should grok just fine,
> AFAICT:
>
> | $ find /usr/share/zoneinfo/ -name Montreal
> | /usr/share/zoneinfo/right/America/Montreal
> | /usr/share/zoneinfo/posix/America/Montreal
> | /usr/share/zoneinfo/America/Montreal
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Vadim Nasardinov

2005-07-20, 8:24 pm

On Wednesday 20 July 2005 15:42, Dave Cramer wrote:
> I think as John pointed out though there are some issues with using
> named TimeZones.

Kris rebutted that comment.

> Is there a way to get the servers timezone info from the server ?

Good question.

Based upon a very cursory reading of the documentation, it seems to be
that PostgreSQL uses a hardcoded internal list of time zones for
dealing with timezone *input*, but it uses the underlying OS's
facilities for dealing with timezone *output*. But then again, the
docs seems to have changed between 7.4 and 8.0. For example, in 7.4:

http://www.postgresql.org/docs/7.4/...e-datetime.html

PostgreSQL uses your operating system's underlying features to
provide output time-zone support,

However, this sentence seems missing from 8.0:

http://www.postgresql.org/docs/8.0/...e-datetime.html

The docs for 7.4 provide a list of timezone abbreviations that
PostgreSQL recognizes:

http://www.postgresql.org/docs/7.4/...e-keywords.html

The 8.0 docs, too, provide the list of abbreviations but also a list
of unabbreviated timezone names:

http://www.postgresql.org/docs/8.0/...e-keywords.html

These seem to be hardcoded.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane

2005-07-20, 8:24 pm

Vadim Nasardinov <vadimn@redhat.com> writes:
> Based upon a very cursory reading of the documentation, it seems to be
> that PostgreSQL uses a hardcoded internal list of time zones for
> dealing with timezone *input*, but it uses the underlying OS's
> facilities for dealing with timezone *output*. But then again, the
> docs seems to have changed between 7.4 and 8.0.

That's because the underlying implementation was completely revamped.
We now have our own timezone code and timezone database (the latter
being the zic database) to avoid depending on the OS facilities.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Vadim Nasardinov

2005-07-20, 8:24 pm

On Wednesday 20 July 2005 18:33, Tom Lane wrote:
> That's because the underlying implementation was completely
> revamped. We now have our own timezone code and timezone database
> (the latter being the zic database) to avoid depending on the OS
> facilities.

If 8.0 comes with its own copy of a recent zic database, then, in
theory, it should be able to handle any timezone known to Java. (The
opposite is not necessarily true, as Java's timezone info seems to be
missing a lot of recent changes.) Does that sound like a correct
statement to you or did I forget some important qualifiers?

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane

2005-07-20, 8:24 pm

Vadim Nasardinov <vadimn@redhat.com> writes:
> If 8.0 comes with its own copy of a recent zic database, then, in
> theory, it should be able to handle any timezone known to Java. (The
> opposite is not necessarily true, as Java's timezone info seems to be
> missing a lot of recent changes.) Does that sound like a correct
> statement to you or did I forget some important qualifiers?

Yeah, it seems that we are just open to version skew issues between
different copies of the zic database ... which changes enough that
that's a nontrivial risk, but I fear we are unlikely to do better.

In any case, it seems that the arguments about which side is likely
to know more timezone names than the other side are moot; we should
not let that consideration drive the design choice.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Oliver Jowett

2005-07-26, 3:24 am

Tom Lane wrote:
> Vadim Nasardinov <vadimn@redhat.com> writes:
>
>
>
> Yeah, it seems that we are just open to version skew issues between
> different copies of the zic database ... which changes enough that
> that's a nontrivial risk, but I fear we are unlikely to do better.

I noticed in passing that Java and postgres have different ideas about
what (for example) "GMT+10" as a timezone name means. Java considers
that to be east of GMT, postgres thinks it is west.

-O

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Sponsored Links