ISO 8601 is an international standard for the formatting of dates and times. It has been adopted by most of the major countries around the world, either directly or as equivalent national standards.

There are a number of options in the standard but the basic idea is that a date is normally represented in the Year-Month-Day format with the Year being four digits and the Month and Day both two digits. Similarly a time is shown as Hour:Minute:Second with each being two digit numbers.

Leading zeros are inserted as required to make each part of a date or time up to the specified number of digits.

A date/time combination to uniquely identify an instant of time is written as the date followed by the time ^*. Therefore, the date and time of writing (24th November, 2002 at 20 minutes past six in the evening) is written:

2002-11-24 18:20

The standard also contains notations for time periods, local times with offsets from UTC, week and month numbers, abbreviated forms (such as the omission of the seconds part, as shown in the example above) and so on.

Obviously, the main advantage of the widespread adoption of a standard is that everybody knows what it means.

What is helpful about this particular standard is that it cannot be confused with any of the previous national standard date formats. The main source of previous confusion was the order of writing months and days. As far as I know, nobody uses the format Year-Day-Month so, with the use of four digit year numbers to identify the first component, the ISO ordering is unambiguous.

The year-month-day order also allows easy sorting.

Clearly, there are a lot of places where dates and times are written which would benefit from the use of this standard.

One of the major activities in computing at the moment is the switch towards XML based file formats. The XML Schema language has been introducted to specify particular structures for documents. It specifies certain "primitive datatypes" including dates and times based on ISO 8601. This will, presumably, make the use of ISO 8601 the simple default for new file formats.

Of particular interest to those who reached this site due to its gliding content, the International Civil Aviation Organization also specifies the use of a similar format. Annex 5 to the Convention On Internation Civil Aviation, Units Of Measurement To Be Used In Air And Ground Operations has an Attachment E, Presentation Of Date And Time In All-Numeric Form, which specifies the use of ISO 2014 for dates and ISO 3307 for times.

From the ICAO references, these standards appear to be simpler predecessors to ISO 8601 so if you stick to the easy cases you can be compliant with both the current international standard and the ICAO standard. The only slightly awkward point is that ICAO has no concept of the "T" notation to separate dates and times.

There seems to be a minor underground campaign to bring this standard into use in various areas.

There's a little web of pages on the subject. Here are few links to get you started:

Implementation

It has been argued that software should display dates and times in the operating system configured local format. This is acceptable for information which is only displayed on the screen for the person for whom the system was originally configured but can cause problems in almost any other circumstances, such as when other users view the system or when documents are e-mailed, printed or viewed across an international network, e.g., as web pages.

In general, I think it is better to stick to the standard all the time.

I have my operating system parameters set up for display in ISO format. Any software which still doesn't manage to do so is treated with at least some degree of contempt.

Y10K

If you're really short of things to worry about you can consider the Y10K problem - ISO 8601 specifies that years be represented by four digit numbers which would cause a panic in the year 9999.

Internet Request For Comments RFC2550, "Y10K and Beyond", which can be obtained from the SunSITE Denmark RFC Archive among other places, proposes a somewhat tongue-in-cheek solution to this problem.

BC

Slightly more seriously, RFC2550 does highlight the omission from ISO 8601 of a notation for years B.C. which might be a consideration in some applications, for example, encyclopaedias or astronomical programs.

Leap Seconds

One aspect of ISO 8601 which I am slightly unhappy about is the definition of a minute as being a period of time of 60 seconds. While this is usually correct (about 99.9997% of the time) I'd rather see it defined as 60 seconds except for the last minute of a day in which leap seconds are applied in which case it is 59 seconds for negative leap seconds and 61 seconds for positive leap seconds. This would:

• make clear which minute the positive leap second 23:59:60 belongs to and
• define the period of time lasting 59 seconds from 23:59:00 to the end of a day with a negative leap second as a minute.

The following is an extract from the Linux (Slackware 3.0) ctime man page:

tm_sec

The number of seconds after the minute, normally in the range 0 to 59, but can be up to 61 to allow for leap seconds.

I think that historically there were occasions when two leap seconds were added at the end of a year but I surmise that this is:

• no longer considered necessary as leap seconds can now be applied at other dates than the end of the year (usually the end of June) and
• no longer considered acceptable as leap seconds are applied as required to keep UTC within 0.9 seconds of UT1 (which is itself dependent on the slightly irregular motion of the Earth) [Duffett-Smith].

Theoretically, ISO 8601 should allow notations like 23:59:61 in order to allow historical times to be expressed correctly.

Note that leap seconds can be applied at various local times. They are always applied at the end of a day UTC and affect local times at the same instant. That is, the offset between UTC and local times is kept fixed. Some countries and areas have local times which are an odd number of half hours off UTC (e.g., 3½ hours) or perhaps a number of hours plus 15 or 45 minutes but as far as I know none now have non-integral number of minutes offsets (Liberia used to, if I remember correctly) so leap seconds may actually be applied to the end of minutes which are not at the end of an hour in local time.

References

[Duffett-Smith] Astronomy with your Personal Computer, Second Edition. Peter Duffett-Smith. Cambridge University Press, 1990. ISBN 0 521 38995 X.

^* The standard specifies a "T" between the date and time when both are given but I think this is intended for file formats and so on in cases where there could be ambiguity.

Being absolutely picky, spaces are not allowed in the ISO 8601 format so putting a space between the date and the time makes them two separate entities - with only the context supplying the relationship between them.