Re: Timestamp Conversion Woes Redux

Yes, it does, my mistake ( It was early here )

However reading the notes about setTimestamp:

When the DBMS does not store timezone information the driver will use
cal to construct a JDBC Timestamp value.
If no Calendar object is specified the driver uses the timezone of
the JVM.

Frustratingly it does not say what to do when the DBMS does not store
timezone information. I guess one could infer that
if it doesn't store timezone information, then timezone information
is ignored ?

Which puts us right back to the original problem... Two SQL types,
and only one setTimestamp.

Onel way to deal with this is to find out what the underlying type
is, or to define a different server type, and cast to deal with this
appropriately. IE Oid.javatimestamp and the cast would be able to do
the right thing based on the underlying type.

Dave
On 20-Jul-05, at 8:30 AM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>
>> In order to calculate the milliseconds the driver takes into
>> account the time zone, information the DBMS may or may not store.
>> If no Calendar object is supplied the driver will use the default
>> Calendar whose time zone is that of the JVM that is
>> running the application. If the DBMS does provide timezone
>> information the driver will simply use that and IGNORE (my caps)
>> a Calendar object that may have been passed to it.
>>
>
> Not having read the source material, but isn't this talking about
> the getTimestamp() path not the setTimestamp() path?
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>