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

Re: [ISO8601] Re: UTC didn't exist before 1961

Expand Messages
  • nguyenivy@gmail.com
    Right. Doesn t the standard call for a proleptic Gregorian calender for dates before 1582 & after the present (and that more digits/negative dates are allowed
    Message 1 of 19 , May 25, 2009
    • 0 Attachment
      Right. Doesn't the standard call for a proleptic Gregorian calender for dates before 1582 & after the present (and that more digits/negative dates are allowed as long as there is mutual agreement)? If you ask me, I believe offsets should be able to contain as much precision as any other time & perhaps the standard should be amended for that at least (aren't offsets are currently limited to hours & minutes from UTC?).

      Sent via BlackBerry from T-Mobile


      From: "Tex Texin"
      Date: Mon, 25 May 2009 08:31:19 -0000
      To: <ISO8601@yahoogroups.com>
      Subject: [ISO8601] Re: UTC didn't exist before 1961

      Did the responses answer your question sufficiently?

      The problem(s) are not really with the standard.
      As you go back in time, UTC doesn't exist, time zones also become less well defined, measurement of time becomes less accurate, the dates of conversion to Gregorian vary around the world, political entities and borders change, and often the author did not record his or her location and "time zone" when noting an event.

      The standard does say that when the standard is used to go earlier that there should be an agreement among the parties using it.
      Wikipedia could document its guidelines to ensure common semantics within microformats.
      Wikipedia can also define some additional metadata to ensure the assumptions made when assigning a date-time with ISO8601 are kept with it so it won't be misconstrued.

      Note also the existence of a year zero, and guidelines on leap days for dates before epoch.

      tex

      --- In ISO8601@yahoogroups .com, "pqrc96" <pqrc96@...> wrote:
      >
      > Some people who write in Wikipedia are interested in using
      > microformats to provide a machine-readable version of important dates
      > and times, in the hopes that future software will be better able to
      > mine data from articles. Dates and times in microformat purport to
      > conform to the ISO 8601 standard, but at least in the case of
      > Wikipedia, the people interested in implementing this sort of thing
      > don't have a clear understanding of time zones or the need to use
      > the Gregorian calendar. Upon re-reading the standard to see if some
      > of these items could be cleared up, I noticed that the standard has
      > an oversignt, in that it allows for dates and times before the
      > beginning of UTC but does not provide a way to specify a time zone
      > for these dates, because doing so requires UTC. In a standard that
      > is so careful to explain the meaning of every single character, this
      > seems like an error. Of course, people will go ahead and extend it
      > backward however they please, but strictly speaking, they are no
      > longer using ISO 8601, they are using their own private extension.
      >
      > --- In ISO8601@yahoogroups .com, "johnmsteele" <johnmsteele@ > wrote:
      > > . . .
      > > What are you trying to do exactly and what time records are you
      > having
      > > trouble relating to UTC?
      >

    • piebaldconsult
      ... True, so we may never know the offset, but that doesn t interfere with using ISO 8601. You can simply indicate local time by not specifying the offset.
      Message 2 of 19 , May 26, 2009
      • 0 Attachment
        >often the author did not record his or her location and "time zone" when noting an event.

        True, so we may never know the offset, but that doesn't interfere with using ISO 8601. You can simply indicate "local time" by not specifying the offset.
      • piebaldconsult
        ... Yes, but seconds generally aren t important in day-to-day events anyway. If you re going to try to calculate an offset to great precision you may need to
        Message 3 of 19 , May 26, 2009
        • 0 Attachment
          > (aren't offsets are currently limited to hours & minutes from UTC?).

          Yes, but seconds generally aren't important in day-to-day events anyway.
          If you're going to try to calculate an offset to great precision you may need to account for continental drift. :)
        • pqrc96
          I started this thread. After seeing the responses, I don t really see anything that would change my ideas, but knowing that my thoughts have been reviewed by
          Message 4 of 19 , May 26, 2009
          • 0 Attachment
            I started this thread. After seeing the responses, I don't really see anything that would change my ideas, but knowing that my thoughts have been reviewed by this group makes me feel more confident in them.

            In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone unless the date is on or after January 1, 1972, the date of the formal adoption of the name Coordinated Universal Time. I will reject incoming dates in that format if I am able to determine that time zones had not been adopted in the place in question on the date stated. I will reject incoming dates with a time zone offset that is not a multiple of 15 minutes.
          • nguyenivy@gmail.com
            I was thinking of historical examples like the offset The Netherlands used sometime in the last 100 years that had an offset precise to the centisecond.
            Message 5 of 19 , May 26, 2009
            • 0 Attachment
              I was thinking of historical examples like the offset The Netherlands used sometime in the last 100 years that had an offset precise to the centisecond. Stating a date/time in ISO 8601 during the period the offset was used could cause problems as the standard doesn't allow for offsets any more precise than minutes. I guess such problems only occur in certain technical applications as in regular writing one could just write the city/town in question with its date & time of the event.

              Sent via BlackBerry from T-Mobile


              From: "piebaldconsult"
              Date: Tue, 26 May 2009 14:09:45 -0000
              To: <ISO8601@yahoogroups.com>
              Subject: [ISO8601] Re: UTC didn't exist before 1961

              > (aren't offsets are currently limited to hours & minutes from UTC?).

              Yes, but seconds generally aren't important in day-to-day events anyway.
              If you're going to try to calculate an offset to great precision you may need to account for continental drift. :)

            • Tex Texin
              Hi, You are welcome to do whatever you want of course, but I don’t think this is what was suggested or recommended and I don’t think you should in any way
              Message 6 of 19 , May 29, 2009
              • 0 Attachment

                Hi,

                 

                You are welcome to do whatever you want of course, but I don’t think this is what was suggested or recommended and I don’t think you should in any way suggest that members of this group endorsed your proposal.

                 

                Personally, I would support using Z going prior to 1972 with the understanding that it refers to GMT.

                Time zones did exist prior to 1972 going back to 1890 for use by trains, and slightly earlier so I would support those as well.

                 

                If I was given a date with a time zone, I would want to record what I was given rather than make a conversion which if I discover later was wrong for that time or locale, I might not be able to correct without knowing the original value.

                 

                Strong rejection policies are a good idea provided your feeds are willing and able to support your model.

                Often, they are not able to conform and tolerance may be necessary.

                 

                Conformance to the standard is a good thing.

                Using the standard in a way that gives you a practical implementation is a better thing.

                Rejecting practical requirements under the guise of conforming to the standard is a bad idea, especially where this standard specifically enables support via mutual agreement.

                 

                tex

                 

                From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of pqrc96
                Sent: Tuesday, May 26, 2009 9:47 AM
                To: ISO8601@yahoogroups.com
                Subject: [ISO8601] Re: UTC didn't exist before 1961

                 




                I started this thread. After seeing the responses, I don't really see anything that would change my ideas, but knowing that my thoughts have been reviewed by this group makes me feel more confident in them.

                In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone unless the date is on or after January 1, 1972, the date of the formal adoption of the name Coordinated Universal Time. I will reject incoming dates in that format if I am able to determine that time zones had not been adopted in the place in question on the date stated. I will reject incoming dates with a time zone offset that is not a multiple of 15 minutes.

              • johnmsteele
                I agree with Tex s remarks. But I would add the following three points: *Dates don t have time zones. Only times or date and time representations have time
                Message 7 of 19 , May 29, 2009
                • 0 Attachment
                  I agree with Tex's remarks. But I would add the following three points:

                  *Dates don't have time zones. Only times or "date and time" representations have time zones. Your views on UTC should never affect a date (standing alone).

                  *Due to its use in astronomy tables, celestrial navigation, etc, GMT or mean solar time on the Greenwich meredian had relevance long before standard time zones, and the "Z" or Zulu notation has been used long before UTC. If a time can be determined to be mean solar time on the Greenich meredian (within a second, or so), a Z notation seems perfectly sensible to me. I would advocate its use, even before it was actually used, just as ISO8601 demands redating dates prior to 1582 to the Gregorian calendar, not the Julian calendar.

                  *Prior to standard time zones, the time offset to GMT was an important concept. If you feel compelled to "destroy the evidence", I would suggest you replace it with the longitude of the official clock in the location. But a time description is equivalent. Usually an hh:mm description to the nearest minute would suffice, but in some cases an extension of the time zone format to hh:mm:ss might be warranted for documented local mean solar time. However, in the time period where this was true, local time may have sufficed perfectly well, and the populace may have been indifferent to what time it was near London.

                  It may pay to ask questions about "suspicious looking" time zones, but, to me, a policy of automatic rejection does not make sense.

                  --- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:
                  >
                  > I started this thread. After seeing the responses, I don't really see anything that would change my ideas, but knowing that my thoughts have been reviewed by this group makes me feel more confident in them.
                  >
                  > In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone unless the date is on or after January 1, 1972, the date of the formal adoption of the name Coordinated Universal Time. I will reject incoming dates in that format if I am able to determine that time zones had not been adopted in the place in question on the date stated. I will reject incoming dates with a time zone offset that is not a multiple of 15 minutes.
                  >
                • Tex Texin
                  John Good comments. I am surprised by your comment on dates. Dates definitely do have time zones. Since time zones span 25 hours, without mention of the zone,
                  Message 8 of 19 , May 29, 2009
                  • 0 Attachment

                    John

                    Good comments.

                    I am surprised by your comment on dates. Dates definitely do have time zones. Since time zones span 25 hours, without mention of the zone, coordinating on date alone could result in a miss with no overlap between them.

                     

                    I know people that needed to be in Australia on date x.

                    Since the flight from their starting point takes 20 hours or so they would plan to leave on day x-1.

                    Unfortunately since their location was about 15 hours behind Australia, they really needed to leave at x-2

                     

                    x-2 + 15 hours time zone difference + 20 hours flying time = x-2 + 1.5 days (35 hours) =~ x

                    Leaving at day x-1 they missed their appointment.

                     

                    I have seen where it makes a difference documenting and comparing  historic dates of events that occurred in widely separated locations.

                    tex

                     

                    From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of johnmsteele
                    Sent: Friday, May 29, 2009 4:39 AM
                    To: ISO8601@yahoogroups.com
                    Subject: [ISO8601] Re: UTC didn't exist before 1961

                     




                    I agree with Tex's remarks. But I would add the following three points:

                    *Dates don't have time zones. Only times or "date and time" representations have time zones. Your views on UTC should never affect a date (standing alone).

                    *Due to its use in astronomy tables, celestrial navigation, etc, GMT or mean solar time on the Greenwich meredian had relevance long before standard time zones, and the "Z" or Zulu notation has been used long before UTC. If a time can be determined to be mean solar time on the Greenich meredian (within a second, or so), a Z notation seems perfectly sensible to me. I would advocate its use, even before it was actually used, just as ISO8601 demands redating dates prior to 1582 to the Gregorian calendar, not the Julian calendar.

                    *Prior to standard time zones, the time offset to GMT was an important concept. If you feel compelled to "destroy the evidence", I would suggest you replace it with the longitude of the official clock in the location. But a time description is equivalent. Usually an hh:mm description to the nearest minute would suffice, but in some cases an extension of the time zone format to hh:mm:ss might be warranted for documented local mean solar time. However, in the time period where this was true, local time may have sufficed perfectly well, and the populace may have been indifferent to what time it was near London.

                    It may pay to ask questions about "suspicious looking" time zones, but, to me, a policy of automatic rejection does not make sense.

                    --- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:

                    >
                    > I started this thread. After seeing the responses, I don't really see
                    anything that would change my ideas, but knowing that my thoughts have been reviewed by this group makes me feel more confident in them.
                    >
                    > In the future, I will not emit ISO 8601 dates with a Z suffix or a time
                    zone unless the date is on or after January 1, 1972, the date of the formal adoption of the name Coordinated Universal Time. I will reject incoming dates in that format if I am able to determine that time zones had not been adopted in the place in question on the date stated. I will reject incoming dates with a time zone offset that is not a multiple of 15 minutes.
                    >

                  • John Steele
                    Tex,   I agree with the dilemma you pose.  In reality, that means date alone often does not suffice and you must consider time of day as well.   However, in
                    Message 9 of 19 , May 29, 2009
                    • 0 Attachment
                      Tex,
                       
                      I agree with the dilemma you pose.  In reality, that means date alone often does not suffice and you must consider time of day as well.
                       
                      However, in being "anal" about interpretting the standard, there is no reference to time zone in the formats allowed for pure dates.  There are formats specified for time and for complete "date and time" references. (sections 4.2 and 4.3, but NOT section 4.1)
                       
                      Any problem must be solved by specifying a place (relative to the date) or by appending a time and time zone.  The standard does not make a provision or provide a format for specifying a time zone with a standalone date.  (At least in my view.  You are better versed in ISO8601 than I; if you can find a section that addresses this, I'll certainly accept it.)

                      --- On Fri, 5/29/09, Tex Texin <textexin@...> wrote:

                      From: Tex Texin <textexin@...>
                      Subject: RE: [ISO8601] Re: UTC didn't exist before 1961
                      To: ISO8601@yahoogroups.com
                      Date: Friday, May 29, 2009, 7:54 AM

                      John

                      Good comments.

                      I am surprised by your comment on dates. Dates definitely do have time zones. Since time zones span 25 hours, without mention of the zone, coordinating on date alone could result in a miss with no overlap between them.

                       

                      I know people that needed to be in Australia on date x.

                      Since the flight from their starting point takes 20 hours or so they would plan to leave on day x-1.

                      Unfortunately since their location was about 15 hours behind Australia, they really needed to leave at x-2

                       

                      x-2 + 15 hours time zone difference + 20 hours flying time = x-2 + 1.5 days (35 hours) =~ x

                      Leaving at day x-1 they missed their appointment.

                       

                      I have seen where it makes a difference documenting and comparing  historic dates of events that occurred in widely separated locations.

                      tex

                       

                      From: ISO8601@yahoogroups .com [mailto:ISO8601@ yahoogroups. com] On Behalf Of johnmsteele
                      Sent: Friday, May 29, 2009 4:39 AM
                      To: ISO8601@yahoogroups .com
                      Subject: [ISO8601] Re: UTC didn't exist before 1961

                       




                      I agree with Tex's remarks. But I would add the following three points:

                      *Dates don't have time zones. Only times or "date and time" representations have time zones. Your views on UTC should never affect a date (standing alone).

                      *Due to its use in astronomy tables, celestrial navigation, etc, GMT or mean solar time on the Greenwich meredian had relevance long before standard time zones, and the "Z" or Zulu notation has been used long before UTC. If a time can be determined to be mean solar time on the Greenich meredian (within a second, or so), a Z notation seems perfectly sensible to me. I would advocate its use, even before it was actually used, just as ISO8601 demands redating dates prior to 1582 to the Gregorian calendar, not the Julian calendar.

                      *Prior to standard time zones, the time offset to GMT was an important concept. If you feel compelled to "destroy the evidence", I would suggest you replace it with the longitude of the official clock in the location. But a time description is equivalent. Usually an hh:mm description to the nearest minute would suffice, but in some cases an extension of the time zone format to hh:mm:ss might be warranted for documented local mean solar time. However, in the time period where this was true, local time may have sufficed perfectly well, and the populace may have been indifferent to what time it was near London.

                      It may pay to ask questions about "suspicious looking" time zones, but, to me, a policy of automatic rejection does not make sense.

                      --- In ISO8601@yahoogroups .com, "pqrc96" <pqrc96@...> wrote:
                      >
                      > I started this thread. After seeing the responses, I don't really see anything that would change my ideas, but knowing that my thoughts have been reviewed by this group makes me feel more confident in them.
                      >
                      > In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone unless the date is on or after January 1, 1972, the date of the formal adoption of the name Coordinated Universal Time. I will reject incoming dates in that format if I am able to determine that time zones had not been adopted in the place in question on the date stated. I will reject incoming dates with a time zone offset that is not a multiple of 15 minutes.
                      >

                    • G Ashton
                      When I mentioned in an earlier post that I would reject certain date-times in the ISO 8601 format, I meant that I would halt processing or flag them for
                      Message 10 of 19 , May 29, 2009
                      • 0 Attachment

                        When I mentioned in an earlier post that I would reject certain date-times in the ISO 8601 format,

                        I meant that I would halt processing or flag them for further attention. The resolution would be

                        on a case-by-case basis. The solution might just be adopting a statement together with the

                        date source along the lines "the date time format for purposes of _______ shall be a

                        non-compatible alteration of the ISO 8601 standard. . ."


                      • piebaldconsult
                        ... Personally, I think that would be fairly silly.
                        Message 11 of 19 , May 31, 2009
                        • 0 Attachment
                          > In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone unless the date is on or after January 1, 1972

                          Personally, I think that would be fairly silly.
                        • Deckers, Michael
                          ... That s fine if your application imposes such restrictions, but it is not what ISO 8601 requires. ISO 8601 fixes some notations but it does not constrain
                          Message 12 of 19 , Jun 2, 2009
                          • 0 Attachment
                            On 2009-05-26, pqrc96 penned thusly:

                            > In the future, I will not emit ISO 8601 dates with a Z suffix or a time zone
                            > unless the date is on or after January 1, 1972, the date of the formal
                            > adoption of the name Coordinated Universal Time. I will reject incoming dates
                            > in that format if I am able to determine that time zones had not been adopted
                            > in the place in question on the date stated. I will reject incoming dates
                            > with a time zone offset that is not a multiple of 15 minutes.

                            That's fine if your application imposes such restrictions, but it is
                            not what ISO 8601 requires.

                            ISO 8601 fixes some notations but it does not constrain the meaning of
                            these notations. Other standards employ some of these notations and
                            endow them with specific semantics.

                            For ISO 8601 timestamps with and without time zone differences,
                            XML Schema ([http://www.w3.org/TR/xmlschema11-2/%5d) is an example. It
                            defines several operations with these timestamps (such as comparison and
                            difference), and gives the semantics of these timestamps as "points on
                            a time line". This is very general, and makes these notations
                            usable for expressing epochs in all kinds of time scales, not just UTC
                            and zone times: navigators can use it for GPS time, astronomers for TCB,
                            and historians for apparent solar time at Jerusalem.

                            Of course it is possible to further restrict the meaning to mean
                            solar time and the civil zone times introduced since 1895, or even to
                            time scales based on TAI, but this is not required by ISO 8601.

                            Michael Deckers
                          Your message has been successfully submitted and would be delivered to recipients shortly.