DOCUMENT TITLE: What Is ISO 8601 ?
AUTHOR: Ian Galpin.
LAST REVISED: 1997-Feb-04.
FORMATTING: 78 Characters per line
FILE NAME: Y2KISO.TXT
What is ISO 8601 ?
------------------
ISO 8601 is an International Standard that defines how dates and times should
be written. It is implemented throughout Europe as EN 28601 and in Britain as
BS EN 28601. In America it is an ANSI standard.
Basically to comply with the 'full' ISO format you need to:
- Use 4-digit years when storing or printing dates.
- Use the order Year-Month-Day for the date, i.e. biggest first.
- Use leading zeroes on the digits 00 - 09 for the month and day numbers.
- Always put the Date BEFORE the Time.
- Use the order hours:minutes:seconds for times.
- Use the 24-hour format for times (not the 12-hour am/pm).
- Use a leading zero on hour, minute and second for digits 00 - 09 inclusive.
- Use UT time scale for dates and times if transferring data internationally.
- When printing dates and times use the '-' and ':' separators.
e.g. 1996-12-31 23:59:59 is the last second of last year.
- When storing dates you can strip off the separators and store as a 32-bit
number, an ASCII string, packed BCD or whatever you like. Sort algorithms
are much easier with this YMD format.
- Times can be treated the same way (sorted or stored), as in the discussion
for dates.
What are benefits ?
-------------------
This format completely eradicates the 04/12/96 ambiguity, where this means 4th
December in Britain and April 12th in America. Having one format usually also
removes some menu options from the program, the program working the same for
everyone everywhere.
By using 4 digits for the year, the software should transition from 1999-12-31
to 2000-01-01 with no problems.
By using the order Year-Month-Day Hour:Minute:Second there is a clear left
to right precedence across all the data elements, and rollover is from right
to left. This also makes programming easier, uses simpler algorithms and often
increases the program speed.
Using leading zeroes in the date and time elements leads to fixed length
records, so mistakes are easier to spot, and lists containing dates and times
are easier to read because the data lines up neatly in to columns.
By using UT time, worries about time zone offsets and about implementation of
Winter/Standard and Summer/'Daylight Saving' times become less relevant. Each
user sets it at their end. The actual data transferred is in the UT time scale
and becomes location independent.
ISO 8601 has mainly been used for scientific applications, especially in
international sciences such as astronomy, where there is a need to exchange
data unambiguously around the globe. Most astronomers leave the System Clock
on UT all year round, and run all software in UT mode. This removes all
confusion. Astronomers work in this format and in UT so that when data is
recorded it becomes location independent. The observer knows his/her
difference from UT and records the data in UT scale. A reader of that data
anywhere else in the world will be able to decode the format (no ambiguity),
and easily add their own UT offset to find out when the recorded event
happened in their own local time scale, should they so wish. Other
organisations and businesses may find this method to be very suitable to
their needs. It has many advantages.
Are there any variations within, or applied to, ISO 8601 ?
----------------------------------------------------------
The standard lays down a 'full' format for calendar date/time (e.g. the last
day of last year is 1996-12-31), and then also defines 'truncated' forms (as
in '96-12-31' says year 96 in any century, December 31st) and 'reduced
precision' (for example '1996-12' specifies only down to month level) formats.
The 'full' format is the most relevant here.
Astronomers have been using the ISO 8601 format to record observations and
transfer data for many years, in fact since before computers were invented.
Astronomers have made one small (unofficial) change to the way that ISO 8601
works. They often write the month as a 3-letter abbreviation. So instead of
writing '1996-12-31' for the last day of last year, astronomers would write
'1996-Dec-31'. This makes the date clearer to those who have not come across
the Year-Month-Day way of writing dates before, but does have the
disadvantage that it may render the date unknown to a non-English-speaking
person. So it is appropriate to perhaps have a menu option on computer
software that allows a choice of the 'Month in Numbers' or 'Month in Words'
on output screens and printouts; so that software may store dates internally
as numbers, but will convert the month to words on computer printouts intended
for human reading e.g. store as '19991231' but print as '1999-Dec-31'.
ISO 8601 has 'extended' and 'basic' formats for each definition. The
'extended' format includes the separators: e.g. 1996-12-31, but the 'basic'
format omits them: e.g. 19961231. The extended format is intended for human
reading, and the basic format is used for data storage (i.e. on hard disk) or
for data transmission.
In most countries, the very last second of last year would be written as
1996-12-31 23:59:59 but in central Europe a slightly different (but equally
acceptable) format may sometimes be used: 1996.12.31-23:59:59 and I see no
problem with that, in fact I prefer it. The '/' symbol should NOT be used in
the date as this has another usage within the standard.
What are the disadvantages ?
----------------------------
Only one, that is that a date like 1996-12-31 may confuse at first glance, but
it takes very little getting used to. There are so many other advantages that
this becomes a minor disadvantage. It is easily overcome if date/time data on
screen has a 'yyyy-mm-dd hh:mm:ss' legend immediately above it. It is a
scientific standard after all, and it has been endorsed as a S.I. unit. The
non-ISO variant with the month as a 3-letter abbreviation also helps clarity.
Any other comments ?
--------------------
Any astronomy program that displays dates and times should use the UT time
scale. It is acceptable for Local Time to be also shown, but if it is, then
both UT and Local should be shown together. It is not acceptable for only
local time to be shown. It can lead to confusion.
Regarding Time Zones, it is common for those East of Greenwich to be treated
as Positive, and for those to the West (i.e. the Americas) to be treated as
Negative. This is also defined towards the end of the ISO 8601 standard.
When the user is asked to enter their 'Local Time Zone Offset From UT' into
the computer program, allowance should be made for the 'non-whole-hour'
offsets that are in force in some countries. Offsets should be allowed for in
15 minute steps, and allow for values up to 14 or 15 hours both ahead, and
behind, UT to be entered.
If the program makes use of the Internal Clock of the Computer System, then
the software should ask the user whether that clock is set to UT or whether it
is running on Local Time. It should also ask the user if Winter/Standard or
Summer/'Daylight Saving' Time is in force, and provide a simple way to change
from Summer to Winter and back again without having to actually change the
numbers of the offset itself.
When a computer program requires dates and times to be entered, it is also
best if they are asked for in the order of Year, Month, Day, Hour, Minute,
Second to follow the general methodology that ISO 8601 imposes on software.
There are already problems with many existing computer programs:
- The use of 2-digit years causes problems when year '99' rolls over to '00'
as will happen in the year 2000.
- The use of British dd/mm/yy and American mm/dd/yy date formats leads to
confusion, ambiguity, and more complicated and slower computer algorithms
to deal with dates.
The coming of the year 2000 and all the problems that it brings to computers
means that many programs are having to be totally re-written; many programmers
are also taking that opportunity to recode using ISO 8601, so that Date/Time
ambiguities around the world can be eradicated at the same time as Y2K
solutions are provided.
A book has been produced by IBM on the subject. So far, it is one of the best
and most comprehensive documents available. It can be downloaded from
Internet. It is located at: http://www.s390.ibm.com/stories/tran2000.html.
The Sixth Edition was released 1996-Dec-30. A paper version can be ordered
from IBM, by quoting Document Number GC28-1251-05 (6th Edition), entitled
'The Year 2000 and 2-digit Dates: A Guide for Planning and Implementation'.
Telephone: 00 1 404 238 1234 for a copy.
Notes for Windows Users:
------------------------
Windows 3.1 and 3.11 can be set up to use the ISO 8601 format. To do this:
In Program Manager, select the following:
- Main - Control Panel - International - Date Format - Change.
- In 'Short Format Date' tick the 'YMD', 'Month Leading Zero', 'Day Leading
Zero' and 'Show Century' options, and change the Separator to '-' (hyphen).
- In 'Long Format Date' select the 'YMD' option and then set the options for
4-digit years, 3-letter months, and 2-digit days (with leading zeroes); it
is optional if you want DayName included or not.
- Click on 'OK' and this returns you to the 'International' screen.
- Then, still in International, select: Time Format - Change.
- Select '24-hour', separator ':' (colon), and 'Leading Zero'.
- Click on 'OK' and this returns you to the 'International' screen.
- Finally, click on 'OK' and Windows should now run in this mode. It may look
strange to begin with, but leave it like that for a week or two - most
people won't want to change back by the end of that time, it makes looking
at lists of dates and times far easier than any other format.
Summary:
--------
- Using the International format (YMD) removes the U.S. (MDY) / U.K. (DMY)
date format ambiguity; and makes the data independent of both the observer
and reader actual locations.
- Using UT time scale also makes the data independent of location.
- Precedence runs from left to right, roll-over runs from right to left across
all data elements.
- Using 4 digits for the year removes problems that occur after year 2000
(00), and differentiates '2000' from '1900'.
- Using all digits for the date means it is understandable all over the world.
The month in words may mean the date is not understandable to a foreign
language speaking person.
- Using a 3-letter abbreviation for the month, helps new users who are
unfamiliar with the Year-Month-Day order.
- Using leading zeroes for month and day means that lists of dates format
nicely into columns making them easier to read (this is also the case with
hours, minutes, seconds for the time).
- Following the Date-Time with 'UT' shows instantly which zone is used.
- Allowing Local Time Zone to be shown (include identifier 'EDT', 'BST' etc!)
helps the general public use the program without removing functionality. It
helps if both UT and Local Time are shown at the same time; but using a
fixed YYYYMMDD-HHMMSS format for both.
1997-02-04\What Is ISO8601
This document is CopyRight Ian Galpin, 19 Palmer Road, Poole, Dorset, England,
BH15 3AR. Permission is given for distribution via Internet and via magnetic
media only. No fee may be charged for this distribution and the document shall
be passed on in full, no alterations are permitted. For permission to reprint
or use in a business environment, write to the author at the address above.
Comments and suggestions on any Y2K or related topic are also always welcomed.
Key Words for Internet Search-Engines: Year2000 Year 2000 Y2K Millennium VHF
Computer Problem Crash Astronomy Date Time Day Julian Gregorian Calendar UHF
ISO Standard ISO8601 ISO 8601 BSEN28601 BS EN 28601 Format Month UTC GMT SHF
JD UT International Program Programming Data Amateur Ham Radio Contest IARU