Re: Timestamp Conversion Woes Redux

Tom,

You are correct, the driver is binding it to a timestamptz. The
underlying data is without
timezone so the server probably attempts to remove it

I'm starting to think that binding the type to "unknown" might be
better as you suggested earlier.

Dave
On 18-Jul-05, at 3:26 PM, Tom Lane wrote:

> 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>