Loading ...
Sorry, an error occurred while loading the content.

ISO-8601 Time and UTC precision questions

Expand Messages
  • hjwoudenberg@aol.com
    The specifications as written for time and UTC Minutes and seconds may be omitted if the time difference is exactly an integer number (00). . Time syntax
    Message 1 of 10 , Nov 1, 2006
    • 0 Attachment
      The specifications as written for time and UTC
      Minutes and seconds "may be omitted if the time difference is exactly an integer number" (00).  .  
      Time syntax maybe:
          hh:mm:ss
          hh:mm
          hh
      UTC syntax:
          ±00:00
           ±00
       
      Are these errors? 
           If time is 12:30 and syntax is hh
          If UTC is +04:30 and syntax is  ±00
       
      Or is the understanding that the syntax permits omitting extra precision if zero.
          hh results in 12:30 on output if minutes are not zero
         .±00 results in +04:30 on output if minutes are not zero
       I see problems with either rule:
          With time, might want to omit minutes or at least seconds even if they are not zero
          With UTC don't ever want to omit minutes if they are not zero.
       
      hjw
    • johnmsteele
      I think you may be taking this out of context. It would be nice if you could give the context (subsection) so we know what you are referring to. Reduced
      Message 2 of 10 , Nov 1, 2006
      • 0 Attachment
        I think you may be taking this out of context. It would be nice if
        you could give the context (subsection) so we know what you are
        referring to. Reduced accuracy local and UTC time are explicitly
        allowed in 4.2.2.3 and 4.2.4 and hh:mm and hh representations do NOT
        require values of minutes or seconds to be zero.

        THe only thing that is "like" your quote is 4.2.5.1 and .2 which is
        about local zone offsets. "Hours only" for the offset is permitted if
        and only if the zone offset is an integer number of hours. There are
        a few "odd zones with 15, 30 or 45 minute offsets. I known of none
        with non-zero seconds. The local time portion can be expressed with
        reduced accuracy or with decimal fraction. The offset must be hours
        and minutes, except hours only is permitted if offset is integer
        hours. The "offset" section makes NO reference to seconds in the
        offset.
        (Section references are to 2004 version)

        --- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
        >
        > The specifications as written for time and UTC
        > Minutes and seconds "may be omitted if the time difference is
        exactly an
        > integer number" (00). .
        >
        > Time syntax maybe:
        > hh:mm:ss
        > hh:mm
        > hh
        > UTC syntax:
        > ±00:00
        > ±00
        >
        >
        > Are these errors?
        > If time is 12:30 and syntax is hh
        > If UTC is +04:30 and syntax is ±00
        >
        > Or is the understanding that the syntax permits omitting extra
        precision if
        > zero.
        > hh results in 12:30 on output if minutes are not zero
        > .±00 results in +04:30 on output if minutes are not zero
        >
        > I see problems with either rule:
        > With time, might want to omit minutes or at least seconds even
        if they
        > are not zero
        > With UTC don't ever want to omit minutes if they are not zero.
        >
        > hjw
        >
      • piebaldconsult
        Yes, I was about to say something like that. Date and time-of-day allow for reduced accuracy , offset from UTC does not. Also... ... I think you mean offset
        Message 3 of 10 , Nov 1, 2006
        • 0 Attachment
          Yes, I was about to say something like that.

          Date and time-of-day allow for "reduced accuracy", offset from UTC does
          not.

          Also...

          > UTC syntax:

          I think you mean offset from UTC, as UTC is Z.
        • piebaldconsult
          It is also possible to have time-of-day in HH and offset in HH:MM e.g. T12+03:30
          Message 4 of 10 , Nov 1, 2006
          • 0 Attachment
            It is also possible to have time-of-day in HH and offset in HH:MM e.g.

            T12+03:30
          • hjwoudenberg@aol.com
            In a message dated 11/1/2006 9:17:57 A.M. Central Standard Time, johnmsteele@yahoo.com writes: I think you may be taking this out of context. It would be nice
            Message 5 of 10 , Nov 2, 2006
            • 0 Attachment
              In a message dated 11/1/2006 9:17:57 A.M. Central Standard Time, johnmsteele@... writes:
              I think you may be taking this out of context. It would be nice if
              you could give the context (subsection) so we know what you are
              referring to. Reduced accuracy local and UTC time are explicitly
              allowed in 4.2.2.3 and 4.2.4 and hh:mm and hh representations do NOT
              require values of minutes or seconds to be zero.

              Are these errors?
              > If time is 12:30 and syntax is hh
              > If UTC is +04:30 and syntax is ±00
              If the precision of the value is greater than of the syntax, is it an errror?
              All examples (except if underline ?)require the precision of the syntax and the value to be the same.
              Common situations:
                  If  hh:mm:ss and time value is 12:30
                  or hh:mm and time value is 12:30:00
               
              how does one handle it?
            • piebaldconsult
              ... an errror? ... syntax and ... I still don t see what your concern is. The partners in interchange mutually agree to use a particular format, it could be
              Message 6 of 10 , Nov 2, 2006
              • 0 Attachment
                > Are these errors?
                > > If time is 12:30 and syntax is hh
                > > If UTC is +04:30 and syntax is ±00
                >
                > If the precision of the value is greater than of the syntax, is it
                an errror?
                > All examples (except if underline ?)require the precision of the
                syntax and
                > the value to be the same.
                > Common situations:
                > If hh:mm:ss and time value is 12:30
                > or hh:mm and time value is 12:30:00
                >
                > how does one handle it?

                I still don't see what your concern is. The partners in interchange
                mutually agree to use a particular format, it could be
                HH
                HH:MM
                HH:MM:SS
                or one of many others. Then the values are formatted as required.

                If HH:MM is agreed upon and one of the partners uses HH:MM:SS instead
                (even if the :SS part is :00), that's an error and the receiving
                partner should throw the data back.

                Is that what you mean?
              • hjwoudenberg@aol.com
                In a message dated 11/2/2006 9:59:50 P.M. Central Standard Time, PIEBALDconsult@aol.com writes: I still don t see what your concern is. The partners in
                Message 7 of 10 , Nov 2, 2006
                • 0 Attachment
                  In a message dated 11/2/2006 9:59:50 P.M. Central Standard Time, PIEBALDconsult@... writes:
                  I still don't see what your concern is. The partners in interchange
                  mutually agree to use a particular format, it could be
                  HH
                  HH:MM
                  HH:MM:SS
                  or one of many others. Then the values are formatted as required.

                  If HH:MM is agreed upon and one of the partners uses HH:MM:SS instead
                  (even if the :SS part is :00), that's an error and the receiving
                  partner should throw the data back.

                  Is that what you mean?
                  Help! Can someone explain?
                   
                  hjw
                • piebaldconsult
                  ... Huh, no else stepped up, I ll try again... If the partners in interchange agree that they don t need the seconds (or minutes) then it doesn t matter what
                  Message 8 of 10 , Nov 7, 2006
                  • 0 Attachment
                    >> I still don't see what your concern is.

                    > Help! Can someone explain?

                    Huh, no else stepped up, I'll try again...

                    If the partners in interchange agree that they don't need the seconds
                    (or minutes) then it doesn't matter what the seconds (or minutes)
                    value is, it gets omitted regardless:

                    So 12:34:56 + THH:MM = T12:34 -- it doesn't matter that the omitted
                    value is 56 (and not 00), the partners agreed to omit the seconds.

                    And as mentioned before, the time-of-day is separate from offset-from-
                    UTC:

                    So 12:34:56 (EST) + THH:MM+HH:MM = T12:34-05:00
                    And 12:34:56 (EST) + THH+HH:MM = T12-05:00

                    In ISO 8601:2004 [4.2.5.1], the statement:

                    "
                    The minutes time element of the difference may only be omitted if the
                    difference between the time scales is exactly an integral number of
                    hours.
                    "

                    doesn't apply to the time-of-day. What it means, is that if the
                    offset for the local time is not a whole number of hours, e.g. if it
                    is +01:30, then you are not allowed to omit the minutes part of the
                    _offset_.

                    So 12:34:45 (+01:00) + THH+HH:MM = T12+01:00 -- is OK
                    And 12:34:45 (+01:00) + THH+HH = T12+01 -- is OK
                    And 12:34:45 (+01:30) + THH+HH:MM = T12+01:30 -- is OK
                    But 12:34:56 (+01:30) + THH+HH = T12+01 -- is _not_ OK
                  • hjwoudenberg@aol.com
                    In a message dated 11/7/2006 12:46:27 P.M. Central Standard Time, PIEBALDconsult@aol.com writes: doesn t apply to the time-of-day. What it means, is that if
                    Message 9 of 10 , Nov 8, 2006
                    • 0 Attachment
                      In a message dated 11/7/2006 12:46:27 P.M. Central Standard Time, PIEBALDconsult@... writes:
                      doesn't apply to the time-of-day. What it means, is that if the
                      offset for the local time is not a whole number of hours, e.g. if it
                      is +01:30, then you are not allowed to omit the minutes part of the
                      _offset_.

                      1. So 12:34:45 (+01:00) + THH+HH:MM = T12+01:00 -- is OK
                      2. And 12:34:45 (+01:00) + THH+HH = T12+01 -- is OK
                      3. And 12:34:45 (+01:30) + THH+HH:MM = T12+01:30 -- is OK
                      4. But 12:34:56 (+01:30) + THH+HH = T12+01 -- is _not_ OK

                      Does everyone agree with example 2
                       
                      What would  12:34:56 (+01:30) + THH+HH:MM = 
                       
                      I understand this example to say the the time offset must match the precision but not the time.   Is that what others understand?
                       
                      hjw 

                    • piebaldconsult
                      No one else wants to jump in? ... That s example number 3. ... How about, The format for the offset-from-UTC must have at least enough precision to accurately
                      Message 10 of 10 , Nov 14, 2006
                      • 0 Attachment
                        No one else wants to jump in?

                        >> 3. And 12:34:45 (+01:30) + THH+HH:MM = T12+01:30 -- is OK

                        > What would 12:34:56 (+01:30) + THH+HH:MM =

                        That's example number 3.

                        > I understand this example to say the the time offset must match the
                        > precision but not the time. Is that what others understand?

                        How about, "The format for the offset-from-UTC must have at least
                        enough precision to accurately represent the offset-from-UTC value to
                        be respresented, regardless of the format used for time-of-day"?

                        It seems you are still thinking of the precisions of time-of-day and
                        offset-from-UTC as connected somehow, they are not.
                      Your message has been successfully submitted and would be delivered to recipients shortly.