[
https://issues.apache.org/jira/browse/OPENJPA-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805978#action_12805978
]
Craig L Russell commented on OPENJPA-1480:
------------------------------------------
I think the user must choose to store the time zone persistently, not assume
that's what the user wants by default. Most usages don't have a time zone
requirement, so making it the default would violate the KISS principle.
I'd like to understand what other implementations do to store time zone in the
database (I'm not volunteering to do the research here). This sounds like an
interesting feature to try to standardize if others have already got
implementations.
As a future enhancement to the standard, I'd suggest a change to the
TemporalType enum:
public enum TemporalType {
DATE, //java.sql.Date
TIME, //java.sql.Time
TIMESTAMP //java.sql.Timestamp
// DATE_WITH_TIMEZONE,
// TIMESTAMP_WITH_TIMEZONE
}
> time zone info lost when using timestamp field
> ----------------------------------------------
>
> Key: OPENJPA-1480
> URL: https://issues.apache.org/jira/browse/OPENJPA-1480
> 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, TestTimeZone.java,
> TZDataModel.java
>
>
> 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.
