"The
great thing about standards is that there are so many of them."
(Anonymous)
From the early
1990's, technical staff of government agencies, financial institutes,
transportation, shipping and manufacturing firms began using the ISO
datestamp standards for programming projects, database structures, operating
system configurations, applications and user interfaces. This was the
new world-wide standard to avoid the frequent, frustrating and often
expensive misinterpretation of datestamps on international communications,
financial transactions, travel plans and deliveries. It also avoided
virtually all issues hovering around the proverbial "Y2K Bug".
There are still
several commonly used notations such as 2/4/3,
2/4/03, 02/04/03,
4.2.2003, 04/02/2003,
4-FEB-2003 and 4-February-2003. Especially the first 5 examples (in
red) should not be used because they have inconsistent interpretations
based on local standards. It is unclear whether
2/4/2003
is intended to mean 2003-04-02 or 2003-02-04 as a common notation within
the U.S. was M/D/Y while the de facto standard notation in virtually
all other nations was D/M/Y. Speaking in percentage of population, of
the 6 billion people on the planet, less than 200 million (about 3%)
would definitively interpret a datestamp of 2/4/2003
to mean 2003-02-04. With consideration of less common, though still
used formats, any date notation which does not use a 4 digit year has
six reasonable interpretations and should never be used.
Also, there are
a growing number of reports of scams and litigation based on the old
datestamp formats. People are asked to sign a contract believing the
datestamp on the document represents a particular due date or process
date, etc., and are caught off guard when the contract is then enforced
to mean another. There have been a number of datestamp interpretation
issues heard in U.S. Federal Courts over the past few years. The datestamp
formats in red above have been successfully argued to mean both the
old U.S. notation (M/D/Y) and the old international standard (D/M/Y).
It is recommended
that when you see any datestamp printed on any legal binding document
in an old datestamp format (as shown in red above) you challenge the
interpretation of the datestamp such that the other party agrees in
writing on the document as to the intended meaning of the notation.
If the datestamp does not use the ISO 8601 format then there needs to
be a subscript key for proper interpretation of the true intended meaning
of the notation as suggested by the following paragraph.
Many people will
compare this world standardization effort to the metric migration. Actually
this is not a good comparison as few individuals would record or present
a measurement without also providing the unit of measure. Those individuals
who wish to continue to use the old M-D-Y or D-M-Y formats should also
always include a subscript (d/m/y, m-d-y, m/d/y, etc.) declaring it
to be of that notation. Also, those individuals who prefer using
the now popular abbreviated ISO 8601 format, YY-MM-DD should also add
the appropriate subscript key (yy-mm-dd). The full YYYY-MM-DD ISO 8601
standard does not require a key.
There Can Be
Only One:
ISO 8601 specifies
numeric representations of date and time. This standard notation virtually
eliminates confusion in international communication caused by the many
different historic national notations. In addition, these formats have
several important advantages for computer usage compared to other traditional
date and time notations. The notations described here are not only already
the de facto standard, but the required official standard in most nations
outside of the U.S..
The international
standard date notation is
YYYY-MM-DD
where YYYY is the
year in the usual Gregorian calendar, MM is the month of the year between
01 (January) and 12 (December), and DD is the day of the month between
01 and 31. Leading "0"'s are always used to pad single digit
days and months.
For example, the
fourth day of February in the year 2003 is written in the standard notation
as
2003-02-04
Advantages of
the ISO 8601 standard date notation compared to other commonly used
variants:
- easily readable
and writeable by software (no 'JAN', 'FEB', ... table necessary)
- easily comparable
and sortable with a trivial string comparison
- the only format
which natively lexicographically sorts chronologically (it has been
shown this one efficiency factor reduces staff costs measurably for
any sized organization)
- language independent
(names of months are not always obvious in translation)
- will not be confused
with other popular date notations
- intuitive and
consistent with all common timestamp notation systems - common sense
that larger units are written in front of smaller units (year-month-day
and hour-minute-second)
- strings containing
a date followed by a time are also easily comparable and sortable
(e.g. write "2003-02-04 22:45:00")
- the notation
is short and has constant length, which makes both keyboard data entry
and table layout easier
- large organizations
embracing the datestamp standard report significant savings in software
development costs
- identical to
the Chinese date notation, so it is already in use within the largest
cultural group (>25%) on the planet
- a 4-digit year
representation avoids Y2K issues and overflow problems after 2099-12-31
(1/1/100 is more than a little concerning)
The Year-Month-Day
Date Format is defined for use in the following standards documents:
International Implementation:
International
Standards Organization: ISO 8601 (1988, 1998, 2000)
(ISO 8601 replaces ISO 2014, ISO 2015, ISO 2711, ISO 3307 and ISO 4031).
Other Major Implementations
of 8601 Standards (represents nearly 65% of the world's population and
95% of the industrialized nations):
-European Norm: EN 28601 (1992)
-USA Standard: ANSI X3.30 (1985 - R 1991)
-USA Standard: NIST FIPS 4-1
-Japan: JIS X 0301 (1992)
-Canada: CSA Z234.5 (1989)
-Australia: AS 3802 (1997)
-South Africa: ARP 010 (1989)
All members of
CEN (all of Western Europe and Scandinavia, and most of Eastern Europe)
are required to adopt the EN 28601 European Standard. Most have now
done so, as detailed below:
-Austria: OENORM EN 28601
-Belgium: NBN EN 28601 (1993)
-Czech Republic: CSN EN 28601
-Denmark: DS/EN 28601
-Finland: SFS-EN 28601
-France: NF EN 28601 (1993)
-Germany: DIN EN 28601 (1993) & DIN 5008 (1996)
-Greece: ELOT EN 28601
-Iceland: IST EN 28601 (1992)
-Ireland: IS/EN 28601 (1993)
-Italy: UNI EN 28601 (1993)
-Luxembourg: ITM-EN 28601
-Netherlands: NEN ISO 8601 (1994) & NEN EN 28601 (1994)
-Norway: NS-ISO 8601
-Portugal: EN 28601
-Spain: UNE EN 28601
-Sweden: SS-EN 28601 (1991)
-Switzerland: SN-EN 28601 (1994)
-United Kingdom: BS EN 28601 Replaces BS 7151 (1992)
-Poland: PN-90/N-01204
When using the Gregorian
calendar, China has been following the ISO 8601 standard since the 1980's.
India has implemented
the 8601 date format within government offices and most international
firms.
As dates looked
a bit strange starting with 2000-01-01 (e.g. like 1/1/0),
it has been suggested that the year 2000 was an excellent motivation
to change to the standard date notation. Most nations around the world
in fact did change over - particularly in the financial, transportation
and shipping sectors.
ISO 8601 is only
specifying numeric notations and does not cover dates and times where
words are used in the representation. It is not intended as a replacement
for language-dependent worded date notations such as "24. Dezember
2003" (German) or "February 4, 2003" (US English). ISO
8601 should however be used to replace notations such as "2/4/3"
and "9.30 p.m.".
Apart from the recommended
primary standard notation YYYY-MM-DD, ISO 8601 also specifies a number
of alternative formats for use in applications with special requirements.
All of these alternatives can easily and automatically be distinguished
from each other:
The hyphens or dot
separators can be omitted if compactness of the representation is more
important than human readability, for example as in
20030204
For situations where
information about the century is really not required, a 2-digit year
representation is available:
03-02-04 or 030204
If only the month
or even only the year is of interest:
2003-02 or 2003
In commercial and
industrial applications (delivery times, production plans, etc.), especially
in Europe, it is often required to refer to a week of a year. Week 01
of a year is per definition the first week that has the Thursday in
this year, which is equivalent to the week that contains the fourth
day of January. In other words, the first week of a new year is the
week that has the majority of its days in the new year. Week 01 might
also contain days from the previous year and the week before week 01
of a year is the last week (52 or 53) of the previous year even if it
contains days from the new year. A week starts with Monday (day 1) and
ends with Sunday (day 7). For example, the first week of the year 2004
lasts from 2003-12-29 to 2004-01-04 and can be written in standard notation
as
2003W52-2004W01
The week notation
can also be extended by a number indicating the day of the week. For
example, the day 2003-12-31, which is the Wednesday (day 3) of the last
week of 2003, can also be written as
2003-W52-3 or 2003W523
for applications
like industrial planning where many things like shift rotations are
organized per week and knowing the week number and the day of the week
is more handy than knowing the day of the month.
An abbreviated version
of the year and week number like
03W522
is sometimes useful
as a compact code printed on a product that indicates when it has been
manufactured.
The ISO standard
avoids explicitly stating the possible range of week numbers, but this
can easily be deduced from the definition:
Theorem: Possible
ISO week numbers are in the range 01 to 53. A year always has a week
52. (There is one historic exception: the year in which the Gregorian
calendar was introduced had less than 365 days and less than 52 weeks.)
Proof: Per definition,
the first week of a year is W01 and consequently days before week W01
belong to the previous year and so there is no week with lower numbers.
Considering the highest possible week number, the worst case is a leap
year like 1976 that starts with a Thursday, because this keeps the highest
possible number of days of W01 in the previous year, i.e. 3 days. In
this case, the Sunday of W52 of the worst case year is day number 4+51*7=361
and 361-366=5 days of W53 belong still to this year, which guarantees
that in the worst case year day 4 (Thursday) of W53 is not yet in the
next year, so a week number 53 is possible. For example, the 53 weeks
of the worst case year 1976 started with 1975-12-29 = 1976-W01-1 and
ended with 1977-01-02 = 1976-W53-7. On the other hand, considering the
lowest number of the last week of a year, the worst case is a non-leap
year like 1999 that starts with a Friday, which ensures that the first
three days of the year belong to the last week of the previous year.
In this case, the Sunday of week 52 would be day number 3+52*7=367,
i.e. only the last 367-365=2 days of the W52 reach into the next year
and consequently, even a worst case year like 1999 has a week W52 including
the days 1999-12-27 to 2000-01-02. q.e.d.
[The new 1999 version
of the C programming language standard (ISO 9899) added in the strftime()
function means to generate the ISO 8601 week notation. The author of
this text developed a further proposal for a modernised clock and calendar
API for C, which provides full proper treatment of leap seconds and
timezones and fixes numerous other problems in the current C timing
library functions. It also serves as a model for those who want to design
clock library functions for other programming languages.]
Both day and year
are useful units of structuring time, because the position of the sun
on the sky, which influences our lives, is described by them. However
the 12 months of a year are of some obscure mystic origin and have no
real purpose today except that people are used to having them (they
do not even describe the current position of the moon). In some applications,
a date notation is preferred that uses only the year and the day of
the year between 001 and 365 (366 in leap years). The standard notation
for this variant representing the day 1995-02-04 (that is day 035 of
the year 1995) is
1995-035 or 1995035
Leap years are years
with an additional day YYYY-02-29, where the year number is a multiple
of four with the following exception: If a year is a multiple of 100,
then it is only a leap year if it is also a multiple of 400. For example,
1900 was not a leap year, but 2000 is one.
Time of Day
The international
standard notation for the time of day is
hh:mm:ss
where hh is the
number of complete hours that have passed since midnight (00-24), mm
is the number of complete minutes that have passed since the start of
the hour (00-59), and ss is the number of complete seconds since the
start of the minute (00-60). If the hour value is 24, then the minute
and second values must be zero. [The value 60 for ss might sometimes
be needed during an inserted leap second in an atomic time scale like
Coordinated Universal Time (UTC). A single leap second 23:59:60 is inserted
into the UTC time scale every few years as announced by the International
Earth Rotation Service in Paris to keep UTC from wandering away more
than 0.9 s from the less constant astronomical time scale UT1 that is
defined by the actual rotation of the earth.]
An example time
is
23:59:59
which represents
the time one second before midnight.
As with the date
notation, the separating colons can also be omitted as in
235959
and the precision
can be reduced by omitting the seconds or both the seconds and minutes
as in
23:59, 2359, or
23
It is also possible
to add fractions of a second after a decimal dot or comma, for instance
the time 5.8 ms before midnight can be written as
23:59:59.9942 or
235959.9942
As every day both
starts and ends with midnight, the two notations 00:00 and 24:00 are
available to distinguish the two midnights that can be associated with
one date. This means that the following two notations refer to exactly
the same point in time:
1995-02-04 24:00
= 1995-02-05 00:00
In case an unambiguous
representation of time is required, 00:00 is usually the preferred notation
for midnight and not 24:00. Digital clocks display 00:00 and not 24:00.
ISO 8601 does not
specify, whether its notations specify a point in time or a time period.
This means for example that ISO 8601 does not define whether 09:00 refers
to the exact end of the ninth hour of the day or the period from 09:00
to 09:01 or anything else. The users of the standard must somehow agree
on the exact interpretation of the time notation if this should be of
any concern.
If a date and a
time are displayed on the same line, then always write the date in front
of the time. If a date and a time value are stored together in a single
data field, then ISO 8601 suggests that they should be separated by
a latin capital letter T, as in 19951231T235959.
A remark for readers
from the U.S.:
The 24h time notation
specified here has already been the de-facto standard all over the world
in written language for decades. The only exception are a few English
speaking countries, where still notations with hours between 1 and 12
and additions like "a.m." and "p.m." are in wide
use. The common 24h international standard notation is widely used now
even in England (e.g. at airports, cinemas, bus/train timetables, etc.).
Most other languages don't even have abbreviations like "a.m."
and "p.m." and the 12h notation is certainly hardly ever used
on Continental Europe to write or display a time. Even in the U.S.,
the military and computer programmers have been using the 24h notation
for a long time.
The old English
12h notation has many disadvantages like:
- It is longer
than the normal 24h notation.
- It takes somewhat
more time for humans to compare two times in 12h notation.
- It is not clear,
how 00:00, 12:00 and 24:00 are represented. Even encyclopedias and
style manuals contain contradicting descriptions and a common quick
fix seems to be to avoid "12:00 a.m./p.m." altogether and
write "noon", "midnight", or 12:01 a.m./p.m."
instead, although the word "midnight" still does not distinguish
between 00:00 and 24:00 (midnight at the start or end of a given day).
- It makes people
often believe that the next day starts at the overflow from "12:59
a.m." to "1:00 a.m.", which is a common problem not
only when people try to program the timer of VCRs shortly after midnight.
- It is not easily
comparable with a string compare operation.
- It is not immediately
clear for the unaware, whether the time between "12:00 a.m./p.m."
and "1:00 a.m./p.m." starts at 00:00 or at 12:00, i.e. the
English 12h notation is more difficult to understand.
Please consider
the 12h time to be a relic from the dark ages when Roman numerals
were used, the number zero had not yet been invented and analog
clocks were the only known form of displaying a time. Please avoid
using it today, especially in technical applications! Even in the
U.S., the widely respected Chicago Manual of Style now recommends
using the international standard time notation in publications.
A remark for readers
from German speaking countries:
The German standard
DIN 5008, which specifies typographical rules for German texts written
on typewriters, was updated in 1996-05. The old German numeric date
notations DD.MM.YYYY and DD.MM.YY have been replaced by the ISO date
notations YYYY-MM-DD. Similarly, the old German time
notations hh.mm and hh.mm.ss have been replaced by the ISO notations
hh:mm and hh:mm:ss. Those new notations are now also mentioned in the
latest edition of the Duden. The German alphanumeric date notation continues
to be for example "3. August 1994" or "3. Aug. 1994".
The corresponding Austrian standard has already used the ISO 8601 date
and time notations before.
ISO 8601 has been
adopted as European Standard EN 28601 and is therefore now a valid standard
in all EU countries and all conflicting national standards have been
changed accordingly.
Time Zone
Without any further
additions, a date and time as written above is assumed to be in some
local time zone. In order to indicate that a time is measured in Universal
Time (UTC), you can append a capital letter Z to a time as in
23:59:59Z or 2359Z
[The Z stands for
the "zero meridian", which goes through Greenwich in London,
and it is also commonly used in radio communication where it is pronounced
"Zulu" (the word for Z in the international radio alphabet).
Universal Time (sometimes also called "Zulu Time") was called
Greenwich Mean Time (GMT) before 1972, however this term should no longer
be used. Since the introduction of an international atomic time scale,
almost all existing civil time zones are now related to UTC, which is
slightly different from the old and now unused GMT.]
The strings
+hh:mm, +hhmm,
or +hh
can be added to
the time to indicate that the used local time zone is hh hours and mm
minutes ahead of UTC. For time zones west of the zero meridian, which
are behind UTC, the notation
-hh:mm, -hhmm,
or -hh
is used instead.
For example, Central European Time (CET) is +0100 and U.S./Canadian
Eastern Standard Time (EST) is -0500. The following strings all indicate
the same point of time:
12:00Z = 13:00+01:00
= 0700-0500
There exists no
international standard that specifies abbreviations for civil time zones
like CET, EST, etc. and sometimes the same abbreviation is even used
for two very different time zones. In addition, politicians enjoy modifying
the rules for civil time zones, especially for daylight saving times,
every few years, so the only really reliable way of describing a local
time zone is to specify numerically the difference of local time to
UTC. Better use directly UTC as your only time zone where this is possible
and then you do not have to worry about time zones and daylight saving
time changes at all.
More Information about Time Zones
Arthur David Olson
and others maintain a database of all current and many historic time
zone changes and daylight saving time algorithms. It is available via
ftp from elsie.nci.nih.gov in the tzcode* and tzdata* files. Most Unix
time zone handling implementations are based on this package. If you
want to join the tz mailing list, which is dedicated to discussions
about time zones and this software, please send a request for subscription
to tz-request at elsie.nci.nih.gov. You can read previous discussion
there in the tz archive.
Other Links about Date, Time, and Calendars
Some other interesting
sources of information about date and time on the Internet are for example
the Glossary of Frequency and Timing Terms and the FAQ provided by NIST,
the Yahoo Science:Measurements and Units:Time link collection, the U.S.
Naval Observatory Server, the International Earth Rotation Service (IERS)
(for time gurus only!), the Network Time Protocol (NTP), the time and
calendar section of the USENET sci.astro FAQ, and the Calendar FAQ.
This was a brief
overview of the ISO 8601 standard, which covers only the most useful
notations and includes some additional related information. The full
standard defines in addition a number of more exotic notations including
some for periods of time. The ISO 8601:2000 standard itself can only
be ordered on paper or as a PDF file on CD-ROM either via ISO's web
site online or from
International
Organization for Standardization
Case postale 56
1, rue de Varembé
CH-1211 Genève 20
Switzerland
phone: +41 22 749
01 11
fax: +41 22 733 34 30
email: sales at isocs.iso.ch
A more detailed
online summary of ISO 8601 than this one is the text ISO 8601:1988 Date/Time
Representations available from ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z
(PostScript, 16 kb, 5 pages) written by Gary Houston, now also available
in HTML. Ian Galpin (G1SMD) proposes to use ISO 8601 as a Common Date-Time
Standard for Amateur Radio. Another summary of ISO 8601 is Jukka Korpela's
page and there are further related pages listed in the Open Directory.
The committee in
charge of ISO 8601 is ISO TC 154 and the editor of the second edition
ISO 8601:2000 was Louis Visser.
