Re: JDBC driver 9.2 sending arbitrary timezone

It appears that the timezone is set at CentOS installation by copying
/usr/share/zoneinfo/Europe/Zurich to /etc/localtime. At runtime, when the
JDBC driver calls TimeZone.getDefault(), the JRE appears to search all
files in the CentOS timezone db (/usr/share/zoneinfo/) until it founds one
that is identical to the one in /etc/localtime. So the result is randomly
Europe/Zurich or Europe/Busingen, since both files are identical in
/usr/share/zoneinfo. If the timezone is set by doing "ln -sf
/usr/share/zoneinfo/Europe/Zurich /etc/localtime", the JRE finds the
intended one directly.

In any case, upgrading to the latest PostgreSQL version also solved it.

Thanks for your help,
Alexandre

On Mon, Aug 5, 2013 at 8:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alexandre Gattiker <agattiker(at)gmail(dot)com> writes:
> > PostgreSQL jdbc jar 9.2-1003-jdbc4 is failing for me, while version
> > 9.1-901-1.jdbc4 works fine. I was able to reproduce the issue by running
> > the jdbc driver's unit tests.
> > It appears the client is sending to the server the
> > timezone Europe/Busingen, although my timezone is set to Europe/Zurich.
>
> According to the Olsen timezone database, Europe/Busingen is an alias for
> Europe/Zurich. So while it's an interesting question why the client side
> is sending "Europe/Busingen" not "Europe/Zurich", you should get the same
> result either way. And it's not hard to imagine that there might be
> logic somewhere inside Java that causes one to be substituted for the
> other.
>
> However, a look into the Olsen source files suggests that Europe/Busingen
> was only added as a zone name in 2011. When was your last server update?
> I don't know whether EDB relies on the system tzdata package, so either
> the postgres package or the tzdata package might be old ...
>
> regards, tom lane
>