Re: Timestamp Conversion Woes Redux

Dave Cramer wrote:
> I looked for this in the trail, and couldn't find it.
> So here it is verbatim
>
> setTimestamp with a calendar
>
> Sets parameter number parameterIndex to x. When the DBMS does not store
> time zone information, the driver will use cal to construct a JDBC
> Timestamp value which it then sends to the database. With a Calendar
> object the driver can calculate the Timestamp object taking into
> account a custom time zone. If no Calendar object is specified, the
> driver uses the time zone of the Virtual Machine that is running the
> application.
>
>
> So my interpretation is.
>
> If we are storing a timestamptz then ignore cal and use the server time
> zone
> If we are storing a timestamp then use cal to calculate the timestamp;
> if cal is null then use the JVM's time zone.

Couple of things..

a) How do we know what type we are storing without invoking UNKNOWN again?
b) The server doesn't actually store timezone information with a
timestamptz (this confused me initially, but Tom clarified), so
shouldn't we be doing what the book says and *using* the calendar when
we store to a timestamptz? (it's just a representation issue, it doesn't
actually affect the value stored in the end.. unless you plug it into a
text column or something..)

> That aside:
>
> If the server provides time zone info, use that to create the
> timestamp, regardless of calendar supplied
> if the server does not provide time zone info, use calendar supplied,
> if that is null or not supplied then use JVM calendar.

That makes sense -- basically it means that if we are reading a
timestamptz we construct the Timestamp directly to represent that
instant, ignoring the calendar supplied. If we are reading a timestamp,
then we turn it into a Timestamp using the provided or JVM-default calendar.

-O