Re: Make time/timestamp tests fair for binary transfers

[Oliver Jowett <oliver(at)opencloud(dot)com>]

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