jms-spec
  1. jms-spec
  2. JMS_SPEC-82

Clarify definition of JMSExpiration, replacing GMT with UTC

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.1, 2.0
    • Fix Version/s: 2.0PD, 2.0
    • Labels:
      None
    • Environment:

      N/A

      Description

      1.1 and the draft 2.0 make multiple references to (Greenwich Mean Time) GMT.
      It would be an improvement to remove all reference to GMT in this standard, and replace with UTC instead.

        Activity

        Hide
        mickhayes added a comment -

        I should add that there is some overlap with JMS_SPEC-44, in that it covers GMT-mentioning parts.
        Regards,
        Mick Hayes.

        Show
        mickhayes added a comment - I should add that there is some overlap with JMS_SPEC-44 , in that it covers GMT-mentioning parts. Regards, Mick Hayes.
        Hide
        Nigel Deakin added a comment -

        Yes, the reference to GMT is somewhat anachronistic, though I note that the Java SE 7 javadocs are not very consistent in this matter (e.g. the method getTime() on java.util.Date refers to GMT, whereas the method currentTimeMillis() on java.lang.System refers to UTC). However I agree UTC is the way to go.

        Adding tag for consideration for the public release.

        It is worth adding that although the JMS 1.1 spec refers to "the GMT at the time of the send or publish" it doesn't specify how the time is represented as a long. I would expect implementation will use System.currentTimeMillis() )(which is the number of ms since a certain time in 1970) but there's nothing in the spec that requires this.

        Show
        Nigel Deakin added a comment - Yes, the reference to GMT is somewhat anachronistic, though I note that the Java SE 7 javadocs are not very consistent in this matter (e.g. the method getTime() on java.util.Date refers to GMT, whereas the method currentTimeMillis() on java.lang.System refers to UTC). However I agree UTC is the way to go. Adding tag for consideration for the public release. It is worth adding that although the JMS 1.1 spec refers to "the GMT at the time of the send or publish" it doesn't specify how the time is represented as a long . I would expect implementation will use System.currentTimeMillis() )(which is the number of ms since a certain time in 1970) but there's nothing in the spec that requires this.
        Hide
        Nigel Deakin added a comment - - edited

        All references have now been changed from GMT to UTC. In addition the definition of the JMSExpiration message header field has been clarified.

        In the JMS 1.1 specification, section 3.4.9 "JMSExpiration", a message's expiration time was defined as "the sum of the time-to-live value specified on the send method and the current GMT value".

        However the JMSExpiration header field is a long value and the specification does not define how the expiration time is converted to a long.

        This has now been clarified to state that it is "the difference, measured in milliseconds, between the expiration time and midnight, January 1, 1970 UTC." This definition is chosen to be consistent with the java.lang.System method currentTimeMillis.

        The updated text can be seen in the JMS 2.0 public draft, section 3.4.9 "JMSExpiration" and in the API docs for the Message method getJMSExpiration.

        Show
        Nigel Deakin added a comment - - edited All references have now been changed from GMT to UTC. In addition the definition of the JMSExpiration message header field has been clarified. In the JMS 1.1 specification, section 3.4.9 "JMSExpiration", a message's expiration time was defined as "the sum of the time-to-live value specified on the send method and the current GMT value". However the JMSExpiration header field is a long value and the specification does not define how the expiration time is converted to a long. This has now been clarified to state that it is "the difference, measured in milliseconds, between the expiration time and midnight, January 1, 1970 UTC." This definition is chosen to be consistent with the java.lang.System method currentTimeMillis . The updated text can be seen in the JMS 2.0 public draft, section 3.4.9 "JMSExpiration" and in the API docs for the Message method getJMSExpiration .
        Hide
        Nigel Deakin added a comment -

        Title changed from "Replace GMT with UTC" to "Clarify definition of JMSExpiration, replacing GMT with UTC"

        Show
        Nigel Deakin added a comment - Title changed from "Replace GMT with UTC" to "Clarify definition of JMSExpiration, replacing GMT with UTC"
        Hide
        Nigel Deakin added a comment -

        This issue is now resolved in the JMS 2.0 public draft. Marking issue as resolved.

        Show
        Nigel Deakin added a comment - This issue is now resolved in the JMS 2.0 public draft. Marking issue as resolved.

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            mickhayes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: