Skip site navigation (1) Skip section navigation (2)

Re: getTiIme/Timestamp with TimeZone inconsistency

From: John Lister <john(dot)lister-ps(at)kickstone(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: getTiIme/Timestamp with TimeZone inconsistency
Date: 2009-05-03 10:41:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Oliver Jowett wrote:
> John Lister wrote:
>> 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?
> I believe this is necessary so that the Time type's invariants (that
> day/month/year is Jan 1 1970 in the specified timezone) are satisfied.
> The driver extends the interpretation of getTime(int,Calender) to mean
> that the returned Time object will be valid for the specified Calendar,
> regardless of whether a timezone was present in the underlying DB or not.
> The underlying timezone, if present, is still used when constructing a
> milliseconds value, but the driver then rotates that resulting value
> into the target timezone. If we don't do that then you get the strange
> result that retrieving a time "01:35:42" while providing a Calendar will
> result in a Time object that does not display as 01:35:42 if you format
> it with that same Calendar. (I hesitate to say whether this is right or
> wrong, because as usual JDBC is woefully underspecified in this area,
> but it's certainly confusing at a minimum)
> -O

I agree the JDBC spec is vague, but I read the spec such that the 
supplied calendar is *only* used if the server doesn't support a 
timezone. I think my main concern is that setTimestamp behaves 
differently to setTime. I'm not sure which is correct (i'd tend to the 
former) but i think they should behave the same...

I'm not sure what the correct behaviour should be if the server has a 
timezone and you specify one to use. Hopefully the app writer would only 
use this case for none timezone columns/results.... maybe too much to 
ask for :)


In response to


pgsql-jdbc by date

Next:From: Tom LaneDate: 2009-05-03 14:41:36
Subject: Re: Very strange performance decrease when reusing a PreparedStatement
Previous:From: John ListerDate: 2009-05-03 10:35:47
Subject: Re: Very strange performance decrease when reusing a PreparedStatement

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group