On Tue, 2007-07-24 at 10:55 +1200, Oliver Jowett wrote:
> Oliver Jowett wrote:
>
> > (I wonder what java.sql.Time.valueOf() returns in timezones ahead of
> > UTC? Might be worth testing..)
>
> Time.valueOf("00:00:00").getTime() returns -43200000 in a +1200
> timezone, so I'd be happier keeping negative values to be consistent
> with that.
OK. I managed to get everything working with binary transfer and the
time
zone dependant normalisation. Just to clarify: the values returned by
ResultSet.getTime are normalised as follows:
GMT-13:00 (+46800000..+133200000)
GMT+00:00 (+00000000..+086400000)
GMT+13:00 (-46800000..+039600000)
The original code already did it this way. Maybe it should be
documented somewhere explicitly so that it is a known decision
instead of just an implementation detail.
Patch description:
The main purpose of the following patch is to make TimezoneTest fair
for binary transfers. The modified test cases now work both on text and
binary protocol (I'll post my new version of it soonish after I have
resolved all remaining unit test case failures).
Previously the code mostly did not test the parsing of
time/date/timestamp values but instead compared the values returned by
ResultSet.getString, which are formatted by the server.
The patched version does now two checks:
1) adds a new verify round that ensures that the insert was correct by
doing an explicit query with UTC timezone and casting all values to
varchar so that the server will format them.
2) Changes all other tests to use the getTime/getDate/getTimestamp
methods when comparing if the queried data is correct.
This basically means that the getString of a time type column is now
undefined and can change. But I think it's not a problem because
different server versions have had different string representation of
time already.
-Mikko