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:
> 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.
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.
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.
> or in UTC, 2002-01-07T16:50Z
> 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.
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
Please also refer to:
for other places where progress is being made.