Timezone on the Calendar object lost in proxying

• Key: OPENJPA-322
• Type: Bug
• Status: Closed
• Resolution: Invalid
• Priority: Minor
• Assignee: Srinivasa
• Reporter: Srinivasa
• Component/s: kernel
• Affects Version/s: 1.0.0
• Fix Version/s: 1.0.0, 1.0.2, 1.1.0

Description

For the Calendar type when the proxy is created the Timezone information is lost.

Comments

[Marc Prud'hommeaux]

I'm backing out this change, since it caused a regression in a test elsewhere.

The current documented behavior is that a Calendar field will always have set the TimeZone that the field was initialized with. For example, if you have a class that defines:

Calendar myCalendar = Calendar.getInstance(TimeZone.getTimeZone("Europe/Budapest"));

and then you later set the field to a different TimeZone, e.g.:

myCalendar = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));

when the instance is persisted and then retrieved, the TimeZone will revert to "Europe/Budapest". Note that this is the only way to maintain consistent behavior so long as we don't actually persist TimeZone data (which we don't).

Also, see section 2.1.1 of the EJB 3.0 Java Persistence API spec, which says: 'Note that an instance of Calendar must be fully initialized for the type that it is mapped to'. That suggests that they expect the TimeZone information in the initialized Calendar to be the one that is used over time.

Please close this issue if you agree with the reversion; otherwise, please put in a comment about why you think the current behavior is incorrect.

[Patrick Linskey]

Could you guys work out what the right behavior is for https://issues.apache.org/jira/browse/OPENJPA-322? I'd like to do a 1.0.2 release, and I noticed that this issue is still open, and that Marc's revert was not made in the 1.0.x branch.

[Craig Russell]

The JPA specification is a bit terse on the requirements, but does say that an @Temporal annotation is required for a persistent field or property of type Calendar, and that 'Note that an instance of Calendar must be fully initialized for the type that it is mapped to'. There are only three database types that the field can be mapped to:
public enum TemporalType {
DATE, //java.sql.Date
TIME, //java.sql.Time
TIMESTAMP //java.sql.Timestamp
}

None of these database types have any storage mechanism for the time zone of the Calendar, and therefore there is no way to construct a Calendar with the time zone of the original Calendar.

Until the specification is changed to allow for storage of the time zone using proprietary database APIs, the only thing I think we can do is to instantiate a Calendar using the default time zone of the caller at the time the field is fetched from the database.

[Srinivasa]

Discussed the same with Marc yesterday, closing the issue.