Mikko Tiihonen wrote:
> The patch also alters what kind of java.sql.Time values are returned.
> Before the patch the millisecond value of a ResultSet.getTime could be
> between -24h<x<24h. The patch changes the returned value to be always
> between 0h<=x<24h. If someone thinks this change is not acceptable I'll
> go back and revert it re-fix the test cases to match.
I'm not sure if this is right. In theory Time values are meant to have a
day/month/year of Jan 1 1970. Time (via Date) uses the local timezone to
compute the day/month/year. But to represent all time values in all
local timezones that means you need negative millisecond values (to
handle timezones ahead of UTC). For example, Jan 1 1970 02:00 +1200 is
actually Dec 31 1969 14:00 UTC, which is a negative milliseconds value.
There's an additional complication that if you're dealing with time
values in different timezones, it'd imply that 2am +1200 is identical to
2pm UTC, which is not entirely true.. they're on different days.
Currently they'd return Time values that are exactly one day apart, with
this change they'd return identical Time values.
As usual, the javadoc is fairly hopeless at telling you how Time is
actually supposed to behave!
(I wonder what java.sql.Time.valueOf() returns in timezones ahead of
UTC? Might be worth testing..)
-O
