Richard Cook wrote:
> Oliver,
>
> Below is the debug output from TimestampUtils.java
>
> It parses the date string that says -05 into an -0400 Date object.
>
> Rich
>
>
> Date String: 2006-10-29 23:00:00-05
>
> debug output ---> Parsed date '2006-10-29 23:00:00-05' in zone
> America/New_York as 2006-10-29 AD 00:00:00 -0400 (millis=1162094400000)
I see no bug here.
(1) Date does not store a timezone offset, so timezone info cannot be
returned in the Date.
(2) getDate() returns a java.sql.Date which by definition must have no
hour/minute/second component (see javadoc)
(3) The driver uses the provided Calendar (or the local JVM timezone if
no Calendar was provided) to generate the Date it will return, in this
case America/New_York (-0400)
(4) The driver discards the hour/minute/second part of the value
returned by the server, and sets the year/month/day on the returned Date
using the Calendar from (3)
So what you end up with is a java.sql.Date for "2006-10-29 00:00:00" in
the -0400 timezone, which is exactly correct in terms of the semantics
of getDate, but isn't actually the same instant as the server returned.
As you have probably worked out by now, using getDate() on a full
timestamp type is a bit confusing because of the H/M/S truncation thing,
especially when timezones are involved. It's arguable whether the driver
should first convert to the timezone of the provided Calendar before
discarding the hour/minute/second component or not .. JDBC doesn't say
anything about how TIMESTAMP to DATE conversion should be done.
If you want to retrieve an instant in time complete with
hour/minute/second info, you should be using getTimestamp() not getDate().
Also note that "timestamp with time zone" does not actually *store* a
timezone, see the docs for details. JDBC doesn't give you any way I can
see to get at the timezone info returned by the server anyway.
-O
