OK. But IMHO, if you are using timestamps outside of PreparedStatements
you are asking for trouble :-). Since you pointed out earlier that most
of the timezones match between java and the server, you could first
attempt to use the server's timezone, and if that doesn't work you could
fall back to this method of using GMT on both client and server.

--Barry

-----Original Message-----
From: Kris Jurka [mailto:books@ejurka.com]
Sent: Wednesday, December 22, 2004 3:27 AM
To: Barry Lind
Cc: Antje.Stejskal@ppi.de; pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Bug in JDBC-Driver?



On Mon, 20 Dec 2004, Barry Lind wrote:

> I haven't been closely following this thread so I may be completely
off
> base here. But wouldn't having both java and the server using the
same
> known timezone have the same effect? So if you were to set the
timezone
> to GMT in both the client and server, timestamps could then be passed
> correctly.
>

I initially thought this was a great idea, but it breaks down when they
don't use a PreparedStatement and generate a query directly, then we
can't
intervene and adjust things. The advantage of setting the server to the
client's timezone is that this will work as expected.

Kris Jurka


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

On Wed, 22 Dec 2004, Barry Lind wrote:

> OK. But IMHO, if you are using timestamps outside of PreparedStatements
> you are asking for trouble :-). Since you pointed out earlier that most
> of the timezones match between java and the server, you could first
> attempt to use the server's timezone, and if that doesn't work you could
> fall back to this method of using GMT on both client and server.
>

My concern is that we don't break things for the situation where the
client and server are already in the same timezone which is 99.9% of the
time.

Kris Jurka


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