Skip site navigation (1) Skip section navigation (2)

Re: Unexpected value in Time object

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: (view raw, whole thread or download thread mbox)
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.


In response to

pgsql-jdbc by date

Next:From: Silvio BiermanDate: 2008-10-29 09:16:49
Subject: Driver memory usage on select and autocommit
Previous:From: Kris JurkaDate: 2008-10-27 23:15:59
Subject: Re: Unexpected value in Time object

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group