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

[ISO8601] Re: German magazine Der Spiegel uses the wrong standard!

Expand Messages
  • g1smd@amsat.org
    On 2002-Jan-14 Bob Niefert wrote( ): [2002-Jan-20] ... When ISO designed the standard, all they had in mind was Information Interchange ; that is, the format
    Message 1 of 3 , Jan 19, 2002
    • 0 Attachment
      On 2002-Jan-14 Bob Niefert wrote(>):


      > I admire your effort and your letter to Der Spiegel.
      > But the example you provided, though an improvement,
      > is itself not ISO 8601.

      > ISO 8601 is for _numerical_ abbreviations of date and
      > time. As soon as you write Jan, you're in verbal mode
      > and ISO 8601 does not apply. Thus I analyze your
      > example further only because it was your intention to
      > present it as an ISO 8601 form.

      When ISO designed the standard, all they had in mind
      was 'Information Interchange'; that is, the format that
      one computer would use when passing information to some
      other system. Original Date and Time standards before
      ISO 8601 date back to at least 1971 (ISO 2014, ISO 2015,
      ISO 2711, ISO 3307, and ISO 4031). This was long before
      PCs, 'The Internet' and many of the electronic gadgets
      that we take for granted today (Video Recorders, PDAs,
      and Mobile Phones), many of which use Dates and Times.

      It is therefore apparent that the ISO format may find
      itself being used for purposes that the ISO committee
      never had in mind, nor could have foreseen, before 30
      years of technology development. This could cover dates
      and times that are shown on screens, printed out on paper,
      stamped on images, or contained in plain language email.
      So date and time problems on an International scale now
      do not just affect computer to computer interchange.
      They are also apparant in the man-machine interface.

      The ISO 8601 standard only deals with numeric dates, but
      ISO have still used the Year-Month-Day order in many of
      the non-numeric examples within the 2000 version of the

      Astronomers have already been doing this for several
      centuries, as I have said before. Nowadays some other
      devices and web sites have also taken up this idea.

      One part of the NASA Web Site located at:
      <http://umbra.nascom.nasa.gov/> has been doing this
      for very many years. They show all dates in the
      Year-Month-Day order, whether numeric or not.

      The IBM Year 2000 Book also used the Year-Month-Day
      ordering, even in long format dates, to good effect.
      There is a copy of this at:

      The search engine located at: <http://ftpsearch.lycos.com/>
      uses the '2001 Feb 03' date format when returning results.
      They use this as a staging point to get people used to the
      Year-Month-Day ordering, before taking the big leap into
      a fully numeric format at some later date.

      I recommend this as a good way to get people started on the
      road to thinking Year-Month-Day for dates.

      >> Thomas Becker -17:50 2002 Jan 7 CEST

      > 1. Jan should be 01.
      > 2. 7 should be 07.
      > 3. Separate date fields with dashes, not spaces.

      > 2002-01-07

      Absolutely, but for human consumption, many would use
      2002-Jan-07, which is now not language independent, nor
      covered by the standard, but which does still retain
      the same logical Year-Month-Day ordering. This looks
      really good in lists of dates, without going fully
      numeric. I certainly recommend it.

      > 4. Time comes after date, separated by T.

      > 2002-01-07T17:50

      Yes, use 24-hour time, and yes, put it after the date
      but for human consumption, the T looks odd, and does
      nothing to enhance legibility. In these cases, many
      would prefer to see this as a separate Date and Time
      separated by a Space. For something shown on screen,
      or printed on paper I would expect this instead of the
      letter T. There has been much discussion here, and
      elsewhere, about this: 2002-Jan-07 17:50 is fine,
      but yes, it must be Date BEFORE Time.

      > 5. Time zone is also numeric; CEST is one hour ahead
      > of UTC. I give precision in minutes because some places
      > are off by a half hour.

      The use of abbreviations for Time Zones, is a relic
      that is confusing, not governed by standards, subject
      to political change, and just plain useless. There is
      mention of this at:
      after earlier attempts to standardise, as shown at:

      The numeric method shown in ISO 8601 is much better,
      but even better still is to convert all dates and
      times to a UTC base for storage and transmission;
      something that astronomers have done for a very long

      Imagine an event that occurs in Japan on Friday 06:00
      Japan Local Time. In USA Winter, this may occur 7 hours
      BEFORE, NOT AFTER!, an event that occurs in the Eastern
      USA on Thursday 23:00 USA Local Time, but will occur
      only 6 hours before the USA event when the USA is on
      it's Summer Time (Daylight Savings) Zone.

      The Japanese event occurs Thursday 21:00 UTC
      The East USA event occurs Friday 04:00 UTC in USA Winter.
      The East USA event occurs Friday 03:00 UTC in USA Summer.

      There is more information in:

      For time zones, you are right to mention the 30 minute
      offset used in some places, but please also note that
      some others are off by 15 or 45 minutes. This receives
      a lot less attention.

      > 2002-01-07T17:50+01:00
      > or in UTC, 2002-01-07T16:50Z

      > Thus...
      > ISO 8601, lange Schreibweise:
      > Thomas Becker - 2002-01-07T17:50+01:00

      For computer storage, this is fine. For something
      in print, I would prefer to see something like:

      2002-01-07 17:50 +01:00
      2002-Jan-07 17:50 +01:00

      The first is an ISO 8601 Date, followed by an ISO 8601
      Time, with an ISO 8601 Time Zone representation.

      It is human parsable and obvious as three separate
      elements: a Date, a Time and a TimeZone. The exact
      ISO 8601 DateTimeZone representation with a 'T' is
      long and complicated to someone not used to such
      things, and, I feel, that this is actually a great
      disadvantage in showing these in print. I prefer
      to break it into three elements.

      The second example format, above, is almost the same,
      but with the month in words. I always prefer this over
      the 07-Jan-2002 or Jan-07-2002 formats.

      One thing that some Internet protocols do, is to allow
      the colon in the Time and disallow it in the Time Zone.
      This also helps human reading. See RFC 2822 for Time
      Zones in this format, though RFC 2822 does NOT use the
      ISO ordering, or format, for the Date.

      > 2002-01-07 17:50 +0100

      > When petitioning an organization to consider ISO 8601,
      > one might direct attention to additional local standards
      > that apply. Referring to Ian's page on national standards,
      > ISO8601:1988 is reflected in European Norm EN 28601:1992
      > and German DIN EN 28601 (1993) & DIN 5008 (1996).
      > Of course ISO8601:2000 is more current.
      > <http://www.qsl.net/g1smd/isoimp.htm>

      Other updates to that list are at:
      One day I will find the time to add those to my own site.

      > The preposterous and dismaying exhibition of Americanisms
      > in date and time notation by non-Americans is likely the
      > result of the hegemony of American software products,
      > rather than a choice to pretend to be American.

      Very probably; which is why we need to target software
      people to include the ISO format in their options, and
      then gradually persuade them to make it the default.

      It can be done; as shown on this web site that I have
      recently found:

      Please also refer to:
      for other places where progress is being made.







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