Tom Lane wrote:
>>>4) When reading from a TIMESTAMP WITH TIME ZONE field, the driver
>>>should create a Timestamp by interpreting the y, M, d, H, m, s values
>>>as UTC timestamp fields. The Calendar, if given, should be ignored.
> Surely 4 should read "by interpreting the y...s values as a timestamp
> in the zone specified as part of the value", not as necessarily UTC.
Yes, you're right.
> The difficulty with both 2 and 3 is that the driver has no very good way
> of knowing whether it's writing to a timestamp with tz or one without.
> We can know the parameter datatype we send, but if that gets converted
> to the other type within the server, you're going to get burnt.
I'm leaning towards using UNKNOWN as the least-bad option for now, plus
some extension mechanism so you can override it if the type inference
does go wrong. Hopefully that should make the commonly-used cases work
without applications needing to do anything weird.
In response to
pgsql-jdbc by date
|Next:||From: Dave Cramer||Date: 2005-07-25 03:06:23|
|Subject: Re: Timestamp weirdness|
|Previous:||From: Tom Lane||Date: 2005-07-24 22:48:10|
|Subject: Re: Timestamp weirdness |