From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | John Pile <john(at)pile(dot)us>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Unexpected value in Time object |
Date: | 2008-10-27 23:50:55 |
Message-ID: | 490653DF.1050609@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Silvio Bierman | 2008-10-29 09:16:49 | Driver memory usage on select and autocommit |
Previous Message | Kris Jurka | 2008-10-27 23:15:59 | Re: Unexpected value in Time object |