Kris Jurka wrote:
>
>
> On Tue, 28 Oct 2008, Oliver Jowett wrote:
>
>> What is your JVM's default timezone?
>> What is the actual value stored in the DB?
>>
>
> The attached test case shows the results of trying to store a Time
> object with one millisecond in a timetz field with a
> America/Los_Angelese JVM timezone.
>
> Orig Time: 16:00:00
> Orig TZ offset: 480
> Orig millis: 1
> Result as String: 16:00:00.001-08
> Result Time: 16:00:00
> Result TZ Offset: 480
> Result millis: 86400001
Ok, after looking at this some more, the driver seems to be doing the
correct thing.
"new Time(1)" is 1 Jan 1970 00:00:00.001 UTC
This is equivalent to 31 Dec 1969 16:00:00.001 -0800
So the original Time value is actually the one that is out of spec if
your default timezone is -0800, since it has a day/month/year that
doesn't match the "zero epoch" requirement of Time.
The result returned by the driver is 2 Jan 1970 00:00:00.001 which is
equivalent to 1 Jan 1970 16:00:00.001 -0800. This appears to be the
correct representation in a -0800 timezone.
The driver is actually constructing the returned Time from a Calendar
initialized like this (using an -0800 calendar)
> cal.set(Calendar.HOUR_OF_DAY, 16);
> cal.set(Calendar.MINUTE, 0);
> cal.set(Calendar.SECOND, 0);
> cal.set(Calendar.MILLISECOND, 1);
> cal.set(Calendar.ERA, GregorianCalendar.AD);
> cal.set(Calendar.YEAR, 1970);
> cal.set(Calendar.MONTH, 0);
> cal.set(Calendar.DAY_OF_MONTH, 1);
which results in the 86400001ms value you see.
java.sql.Time is generally a horrible interface to work with, since it
depends so much on the default JVM timezone :( About all you can do with
it is work in the default timezone and use
getHours/getMinutes/getSeconds/getMilliseconds. The actual milliseconds
value used internally to represent a particular time will vary wildly
depending on the JVM's timezone.
-O