Timestamp changes committed to HEAD - Mailing list pgsql-jdbc
From | Oliver Jowett |
---|---|
Subject | Timestamp changes committed to HEAD |
Date | |
Msg-id | 42EDC90C.4040506@opencloud.com Whole thread Raw |
Responses |
Re: Timestamp changes committed to HEAD
(Kris Jurka <books@ejurka.com>)
Re: Timestamp changes committed to HEAD ("emergency.shower@gmail.com" <emergency.shower@gmail.com>) Re: Timestamp changes committed to HEAD (Kris Jurka <books@ejurka.com>) |
List | pgsql-jdbc |
I've committed my Timestamp/Date/Time changes to CVS HEAD; here's the commit message. With these changes {get,set}{Timestamp,Date,Time} should respect Calendars properly and not make any assumptions about server timezone vs. JVM timezone. Assuming this works as people expect (please test!), any thoughts on whether this is suitable to backport to 8.0? It *is* a big set of changes, but the stable driver is pretty broken in this area as it stands. -O Timestamp/Time/Date work per discussion on pgsql-jdbc. Rewrote quite a bit of TimestampUtils so that timezones are correctly handled both when parsing and when stringizing values. TimestampUtils is now an instance attached to the Connection so we can have different behaviour for 7.3 vs. 7.4 (7.3 does not allow timezone specifications in time literals). Added TimezoneTest to test all the various legal conversions when Calendars are involved. Server versions and what they support: 8.0: everything works 7.4: everything works 7.3: setTime()->timetz, setTimestamp()->time fail 7.2: setTime()->timetz, setTimestamp()->time, +1300 timezones fail The problem with setTime() on timetz is that we can't pass the timezone down in <=7.3 in case it's actually a time value that is expected, so the timetz will always end up with the server's TimeZone regardless of the Calendar passed. A similar problem affects setTimestamp() as it must pass a timezone down in case the expected type is timestamptz, which will fail if the expected type is actually time. We can't fix these cases by asking the server for the actual type expected, as that requires protocol v3 which 7.2/7.3 don't support. The +1300 timezone problem is a server bug in 7.2 (possibly fixed in later 7.2 releases, haven't checked); +1300 is a legal timezone but 7.2 doesn't accept it. Oid.UNKNOWN is now used for setTimestamp() and setDate(). It's unfortunately necessary for setDate() to handle setDate(i,date,calendar) when the underlying column is a timestamptz, for much the same reasons as the timestamp/timestamptz issue -- we need to avoid an unwanted rotation by the server's TimeZone setting. Cleaned up some of the tests in TimestampTest so they don't break when the JVM's timezone is different to the server's timezone. Still broken: CallableStatement.get{Date,Time,Timestamp} with Calendar. Fixing this will like require some rearrangement of when OUT parameters are turned into Objects.
pgsql-jdbc by date: