Re: Timestamp Conversion Woes Redux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Cryder <c(dot)s(dot)cryder(at)gmail(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Timestamp Conversion Woes Redux
Date: 2005-07-18 19:26:49
Message-ID: 16335.1121714809@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Christian Cryder <c(dot)s(dot)cryder(at)gmail(dot)com> writes:
>> The problem isn't with PreparedStatement, rather with Timestamp itself.

> Actually, I still think it is a problem w/ PreparedStatement, and I'll
> see if I can explain why, as well as provide a better test case to
> illustrate.

I'm hardly a JDBC expert, but I recall some considerable discussion
awhile back about how JDBC ought to map Java's (one) Timestamp type
into Postgres' TIMESTAMP WITH/WITHOUT TIME ZONE types, neither of
which apparently match the semantics of Timestamp very well. You
should go digging in the pgsql-jdbc archives for background.

As for the problem at hand, I suspect that the driver is prespecifying
the parameter data type as either TIMESTAMP WITH or TIMESTAMP WITHOUT
TIME ZONE, and that whichever choice is used is different from what
the server would infer without the prespecification. This would in
turn affect what the server assumes about the timezone spec (or lack
of one) in the supplied input string. Worse, there could be an
ensuing run-time conversion between the two data types, leading to
adding or subtracting your local GMT offset.

(For that matter, is the parameter being sent in text or binary?
If it's binary then most of these theories fall to the ground...)

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2005-07-18 19:38:43 Re: Debugging the JDBC drivers...
Previous Message Dave Cramer 2005-07-18 19:16:27 Re: Debugging the JDBC drivers...