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

Re: UTC didn't exist before 1961

Expand Messages
  • johnmsteele
    8601 also requires the use of the Gregorian calendar, which did not exist prior to 1582, for all dates. It is easy to extrapolate back. For time, the concept
    Message 1 of 19 , Feb 28, 2009
    • 0 Attachment
      8601 also requires the use of the Gregorian calendar, which did not
      exist prior to 1582, for all dates. It is easy to extrapolate back.

      For time, the concept of time zones and radio time signals synchronized
      between countries certainly existed before 1961. The prevalent time
      standard was UT2, a form of rotational time smoothed for seasonal
      variation, and high precision clocks were steered to match it. Until
      1972, atomic clocks were steered to it, prior to leap seconds. Prior
      to the introduction of atomic time, I think you could substitute that
      with little loss of accuracy.

      If you go back another century, there were no time zones, everyone kept
      local solar time, and clocks weren't very good anyway. However there
      are records of departure of local time from time on the prime meredian
      that are part of the time zone record.

      What are you trying to do exactly and what time records are you having
      trouble relating to UTC?


      --- In ISO8601@yahoogroups.com, "pqrc96" <pqrc96@...> wrote:
      >
      > All the parts of the standard that discuss Universal Time or time
      zones
      > specify that everything is based on Coordinated Universal Time (UTC).
      > But UTC didn't exist before 1961, and didn't assume its present form,
      > with an integer number of seconds difference between International
      > Atomic Time (TAI) and UTC until 1972. So isn't it formally incorrect
      to
      > use the Z indicator or a time zone offset before 1961?
      >
      > For the relationship between TAI and UTC see
      > http://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history
      >
    • pqrc96
      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
      Message 2 of 19 , Feb 28, 2009
      • 0 Attachment
        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
        No.
        Message 3 of 19 , Apr 4, 2009
        • 0 Attachment
          No.
        • johnmsteele
          In a very strict technical sense it may have been overlooked. However, prior to atomic clocks, you have to relax the formality of beating in synch with atomic
          Message 4 of 19 , May 23, 2009
          • 0 Attachment
            In a very strict technical sense it may have been overlooked.


            However, prior to atomic clocks, you have to relax the formality of beating in synch with atomic clocks. It obviously approximates (within 0.9 s, that is why leap seconds are used) mean solar time at Greenwich. Formerly that time was kept as GMT or UT1 (Note: GMT had a confusing period where astronomers counted from noon, and civilly, hours were counted from midnight). GMT was used from 1884 when Greenwich was accepted by international convention as the Prime Meredian (and used by many nations prior to that).

            Your bigger problem is when did political entities switch from local mean solar time to standard time. In most places it was adopted first by railroads and some local entitites, eventually national. The US was 1918, with some prior use by individual cities and states.

            The "Z" designation for time at Greenwich was used long before UTC.

            I think your 1961 boundary can be pushed back to when the country of interest declared "standard time" (if you can determine how many hours off Greenwich. There are a LOT of time zone changes.)

            Prior to standard time, there may be a problem, although if you know the longitude of a place, you could calculate the time shift from Greenwich to the nearest minute (1 hour/15°). Rarely are times back then known with any great accuracy.

            --- 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
            I don t see a problem.
            Message 5 of 19 , May 24, 2009
            • 0 Attachment
              I don't see a problem.
            • Tex Texin
              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
              Message 6 of 19 , May 25, 2009
              • 0 Attachment
                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?
                >
              • 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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.