getTiIme/Timestamp with TimeZone inconsistency

From: John Lister <john(dot)lister-ps(at)kickstone(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: getTiIme/Timestamp with TimeZone inconsistency
Date: 2009-05-02 13:23:43
Message-ID: 49FC495F.1020302@kickstone.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Looking at getTime and getTimestamp in TimestampUtils as used by the
getTime(int, Calendar) and getTimestamp(int, Calendar) functions in
AbstractJDBC2ResultSet there seems to be an inconsistency:

The API docs for these state "This method uses the given calendar to
construct an appropriate millisecond value for the time if the
underlying database does not store timezone information. "

and in TimestampUtils .getTimestamp if the server returns a timezone, it
is used instead of the supplied calendar.

However in TimestampUtils.getTime, this is initially done, but then
reversed further down and the supplied timezone is used as follows:

if (ts.hasDate) {
// Rotate it into the requested timezone before we zero out
the date
.....
cal.setTime(new Date(useCal.getTime().getTime()));
useCal = cal;
}

is there a reason for this as it seems inconsistent with getTimestamp
and the api docs?

Removing this makes the unit test TimezoneTest.testTime more consistent
(the first group of tests all return the same value - instead of the
last one being negative)

I ask as i'm playing with the adding binary wire transfer and Mikko
Tiihonen original patch omitted time/dates as he reported they failed
the unit tests.

Thanks

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2009-05-02 23:35:55 Re: getTiIme/Timestamp with TimeZone inconsistency
Previous Message Adam B 2009-05-01 21:06:00 Re: A basic Statement.getGeneratedKeys() implementation (patch attached)