openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B.J. Reed (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1480) time zone info lost when using timestamp field
Date Wed, 27 Jan 2010 21:14:34 GMT


B.J. Reed commented on OPENJPA-1480:

DBDictionary.getCalendarI() is used to get the Calendar object, by
   1) Use getDate() which gets a Date object in local time
   2) creates a Calendar and does setTime from the Date object

In OPENJPA-322, there was a fix in SingleFieldManager that was backed out. This fix is way
too late in the processing since the correct time zone should be gotten when DBDictionary
does getDate

The TestCalendarField test case has a problem... patch being provided to improve the test
case.  Because the Time Zone is always set to Budapest any time that a TemporalFieldTypes
entity is instantiated, then the test case will always pass, regardless of what is received
from the DB.

I have confirmed what Craig says above.  My suggestion is that for these TEMPORAL objects,
we use "timestamp with time zone" when possible as the default, but when that's not possible,
OpenJPA needs to create a 2nd field in the DB specific to this purpose.

> time zone info lost when using timestamp field
> ----------------------------------------------
>                 Key: OPENJPA-1480
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 1.2.3, 1.3.0, 2.0.0-M3, 2.0.0-beta
>         Environment: at least DB2, Derby, Sybase
>            Reporter: B.J. Reed
>            Priority: Minor
>             Fix For: 1.2.3, 1.3.0, 2.0.0
>         Attachments: OPENJPA-1480-TestCalendarField.patch,,
> Looks like OpenJPA always gets the time stamp out at the time zone of the machine, not
the time zone that was used originally.
> The test case is putting in 2 TimeStamps
>     TTimestamp = 4-3-2004 21:0:0.0 (America/New_York)
>     TTimestampUTC = 4-4-2004 2:0:0.0 (UTC)
> When OpenJPA gets those 2 timesamps back out of the database, they are 
>     TTimestamp = 4-3-2004 21:0:0.0 (America/New_York)
>     TTimestampUTC = 4-3-2004 21:0:0.0 (America/New_York)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message