OpenJPA
  1. OpenJPA
  2. OPENJPA-322

Timezone on the Calendar object lost in proxying

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.0.0, 1.0.2, 1.1.0
    • Component/s: kernel
    • Labels:
      None

      Description

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

        Issue Links

          Activity

          Hide
          Srinivasa added a comment -

          Discussed the same with Marc yesterday, closing the issue.

          Show
          Srinivasa added a comment - Discussed the same with Marc yesterday, closing the issue.
          Hide
          Craig L Russell added a comment -

          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.

          Show
          Craig L Russell added a comment - 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.
          Hide
          Patrick Linskey added a comment -

          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.

          Show
          Patrick Linskey added a comment - 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.
          Hide
          Marc Prud'hommeaux added a comment -

          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.

          Show
          Marc Prud'hommeaux added a comment - 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.

            People

            • Assignee:
              Srinivasa
              Reporter:
              Srinivasa
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development