In most contexts, unqualified dates before 1582 are assumed Julian, and those after 1752 are assumed Gregorian; local dates are commonly in the then-current local calendar.
Unless words are used, the only unambiguous unqualified formats for writing the Gregorian date are those using the order YYYY-MM-DD. The best format for writing the time is 24-hour HH:MM[:SS], and it should follow, rather than precede, the date, and be followed by a time offset indication if appropriate. These are among the ISO 8601 standard formats; the date field separator should be a hyphen though many prefer '/'. YYYY should have four digits; MM & DD must always have two digits, as must HH MM & SS.
Additionally, these formats are easy to compare and sort as strings, and tabulate well.
Some systems can introduce line-breaks in hyphenated words, and/or stretch them in justified text. For these, if there is no non-breaking hyphen, YYYY/MM/DD may be preferred.
Those who, in international media, use a numerical date form with M-D-Y order are showing a callous disregard for others. I hear that within Canada both D-M-Y and M-D-Y are common ... .
The year description CCYY, used where YYYY would have been appropriate, is, at best, ambiguous (CCYY can be, and has been misinterpreted in at least three ways :- learned, such that 1901-2000 is CC=20; demotic, such that 1900-1999 is CC=20; and IBM, such that one of those is CC=0 and now CC=1).
Those who wish to change from YY/MM/DD (or DD/MM/YY, &c.) to use four-digit years, but who have no room for field expansion, should use YYYYMMDD, which is also ISO compliant.
Another compliant day representation is like yyyy-Www-d, where 'W' is "W", 'ww' is the ISO Week Number, 'd' the day number within it (Mon=1..Sun=7), and 'yyyy' is the year number of the week, which is (for December 29th to January 3rd) not necessarily the calendar year number.
Another is like yyyy-ddd, where 'ddd' is the day number (1..366) within the calendar year 'yyyy'.
There was a US traveller who, in September 2000 or thereabouts, thought that his European visa would still be good because its expiry date was given as 10/08/2000 or suchlike. See Risks Digest 21.23, #24.
Some software may do its best to interpret a string as some date or other. "28/03/95" is umambiguously 1995-03-28, if the date can be assumed to be more or less current (but JavaScript can take it as 1995-28-03 = 1997-04-03). The chief problem in practice is with the orders DMY and MDY : a test of "28/03/95" does not necessarily indicate whether "02/04/96" would be taken as 2nd April or February 4th. Date-interpreting software needs to be tested with Y M D all different and in the range 1..12.
Test also what happens to two-digit years both large and small.
The difference between a local time or time zone and GMT can be written, for example, as +0530 or +05:30. It appears that ISO 8601 and Internet practice may differ as to whether '+' means East or West of Greenwich - see at davros. ISO uses '+' for Asian times and '-' for American.
The following, among others, could be encountered, together with their obvious variations, permutations, expansions, truncations, and punctuations :-
In a given system, it is wise to use only a single, complete, canonical form for the date and time, converting to/from derived forms as needed. In administrative work, a single number should be an integer; in technical work, it can be floating-point. With, naturally, exceptions.
The following, among others, could be encountered, together with their obvious variations, permutations, expansions, truncations, and punctuations :-
Use the 24-hour clock, with such formats as 13:24, 13:24:25, 13h24, or 1324h - everyone can understand it nowadays.
Both 1999-12-31 24:00:00 and 2000-01-01 00:00:00 are alternative representations of the same moment (there was no Leap Second on that occasion; and, if there had been, the statement would still be valid, since the Leap Second would have been 1999-12-31 23:59:60).
Some bodies have been said to prefer to consider their internal day as extending over a different range, showing the time accordingly and changing the date other than at midnight = 24:00; confirmation and brief details are requested.
Likely examples : public transport, 03:00 up to 27:00; London transport Oyster, 04:30 up to 28:30; broadcasting, 06:00 up to 30:00.
I hear that NYC (New York City?) "one-day passes" are valid from 3 a.m. to 3 a.m.; but that is not quite the same thing.
There is a weak convention that Midnight of a date ends that date; but it can often be ignored, or over-ruled by context. When the beginning of an interval is being describes, Midnight probably means 00:00 of the date given.
The hours of the 24-hour clock run from 00 to 23. But 24:00 may be used to mean the end of the day.
The hours of the 12-hour clock run, by Western custom, from 1 or 01 to 12; but the letters change at noon and at midnight.
Properly, AM is ante meridiem, and lies between 00:00:00 and 12:00:00, NON-inclusive of the end instants; and PM is post meridiem, between 12:00:00 and 24:00:00, NON-inclusive. Thus 00:00:00, 12:00:00, 24:00:00 are neither AM nor PM. But in practice 12.00 AM probably means the earlier midnight, and 12:00 PM means midday, by analogy with the hours that they start. For a US view, see at NIST.
However, one cannot rely on either authors or readers understanding AM & PM correctly.
With AM & PM, sorting is hazardous, since 12:30 is before 11:30.
Any use of the 12-hour clock in computing is sheer folly (except that it makes a nice pedagogic exercise), as indeed is the use of any date/time format not approved by ISO 8601.
| Comparison of 12- and 24- Hour Clocks for One Date | |||||||
|---|---|---|---|---|---|---|---|
| 24-Hour | 00:00 | 00:01 - 00:59 | 01:00 - 11:59 | 12:00 | 12:01 - 12:59 | 13:00 - 23:59 | 24:00 |
| 12-Hour | --- | 12:mm a.m. | hh:mm a.m. | Noon | 12:mm p.m. | hh:mm p.m. | Midnight |
| ?? | 12:00 a.m. | 12:00 p.m. | --- | ||||
| 01 ≤ hh ≤ 11 00 ≤ mm ≤ 59 | |||||||
For a means of converting 12-h time to sortable strings without complete conversion, see via JavaScript Date and Time 0 : Date Object Information.
I have read that the Japanese use 0 AM & 0 PM for midnight & noon.
Dates and times in ISO 8601 formats are understandable everywhere, without ambiguity; and they can be sorted correctly as strings.
ISO 8601:2004(E)
ISO 8601 itself, Data elements and interchange formats -- Information interchange -- Representation of dates and times, supersedes ISO 2014, ISO 2015, ISO 2711, ISO 3307 and ISO 4301.
The standard is maintained by ISO TC 154.
The Standard covers three distinct types of numeric date representation, time representation, time interval, and recurring time interval.
The Standard is well described, with links, in Wikipedia.
ISO 8601 cites ISO 31 Quantities and units - 31-0: General principles, 31-1: Space and time.
I have ISO 8601:1988 revised 1991, ISO 8601:2000 and ISO 8601:2004.
A Google search for "ISO 8601:2004" or "ISO 8601:2004(E)" apparently finds one or more copies.
Earlier, ISO did not make their Standards available on-line; however, I was sent a copy of the final draft of ISO 8601:2000. G1SMD has links to various copies of various versions.
ISO 8601 has been widely adopted as, for example :-
Is there an EN standards site, and can ENs be downloaded?
European Norms are issued by three bodies :-
•
CEN
(European Committee for Standardisation)
•
CENELEC
(European Committee for Electrotechnical Standardisation)
•
ETSI
(European Telecommunications Standards Institute)
CENELEC is responsible for the area of electrotechnics, ETSI for the area of telecommunications, and CEN for all the rest.
Copies of standards issued by CENELEC or ETSI are available from the respective websites, also as a download, but not for free. Copies of all EN standards are available through the national standards bodies of the participating countries.
Where in the UK can such standards be read or borrowed? (other than on the Web!)
In Section 3.2.1, ISO 8601:2004 describes the nature of the Gregorian Calendar. It cites no other authority for the Calendar, but concedes introduction in 1582.
It exactly defines the positioning of weeks (2000-01-01 is a Saturday, Day 6 of 1-7 [2001-01-01 as Monday would be more elegant, being the start of a Millennium and the start of a Week]).
ISO 8601:2000 assigned 1875 to the signing of the Convention du Mètre in Paris, thereby only loosely indicating the positioning of the sequence of dates on the sequence of natural days. ISO 8601:2004 assigns 1875-05-20 to the signing of the Convention.
The formal reference point for the Gregorian Calendar is Gregorian 1582-10-15, decreed by Papal authority to be the day following Julian 1582-10-04; or, by British law, 1752-09-14 following 1752-09-02.
A more-or-less reproducible reference could have been be provided by a suitable retrodictable astronomical event, such as the Solar Eclipse of August 1999.
I doubt the description of the average duration of the Calendar Year.
ISO 8601:2004 2.2.13 has "calendar year cyclic time interval in a calendar which is required for one revolution of the Earth around the Sun and approximated to an integer number of calendar days". ISO 8601:2000 3.30 had similar wording.
Taken literally, that revolution can only be with respect to the "Fixed Stars". But the fundamental requirement on the Calendar Year from time immemorial is that it should be locked to the cycle of the four seasons; it is that which governs the provision of leap years. The seasons are caused by the tilt of the Earth's axis with respect to its orbital plane. The axis slowly precesses, and that is generally described by the Precession of the Eqinoxes; the period is about 25800 years. The difference is 39 ppm, about twice the Gregorian Correction.
The ISO preferred formats are derived from these extended forms :-
| Calendar Date | yyyy-mm-dd | |||
| Ordinal Date | yyyy-ddd | yyyy is the same | ||
| Week Date | yyyy-Www-d | yyyy may differ | ||
| Time of Day | hh:mm:ss | (24-hour) |
All fields - from years to seconds - have leading zeroes where necessary to bring them to the lengths shown above.
The date separator should ideally be a hyphen, not a minus (−). The hyphen should be non-breaking, so that the date is not split between lines. But the keyboard character hyphen-minus, #45 (-), is commonly used.
A number of countries use that date field order, but with different separators; "/" and "." are common, and the latter has the advantage that a date cannot be parsed as a valid numeric expression.
Day-of-Week is Monday=1 to Sunday=7, all weeks having 7 days; Week Number 01 of a year contains January 4th.
Between Date and Time, I often use a space (allowed from :2004) instead of a T (required in :2000), but the T does make the data into a single "word".
The formats are unambiguous, readily sortable, and fixed-width (for the next 7.99 millennia). Only the 24-hour clock is used. Trailing "Z" represents UTC; no other letters are put there - a signed numeric offset is used.
Intended for use in DOS batch flles, my program NOWMINUS can be used to put the current date, time, or both, less any given numbers of years ... seconds, and with other adjustments, in various ISO 8601 formats including CJD, Y M D & Y W D (and D M Y), into an environment variable or variables, or elsewhere. ENVICALC does general RPN integer arithmetic.
Where field separators are used, leading zeroes can be omitted without ambiguity. But they should nevertheless be included, for the following reasons :-
Leading zeroes are generally not used in Full Years, though spaces may be used for layout and zeroes also for emphasis. They should always be included for years 00..09 of a "century" other than the first and its previous one.
Where there are no field separators, it can be harder to recognise that the digit string represents a date; worse, if leading zeroes are omitted in month and day there are occasional ambiguities - even more so if there can be uncertainty as to whether the field order is YMD, MDY, or DMY.
If the field order is known, the ambiguity-to-come may not be noticed in initial testing.
| Digit String | Can be seen to mean | ||
|---|---|---|---|
| YMD (JP) | MDY (US) | DMY (EU) | |
| 11111 | 2011 Jan 11 2011 Nov 01 | Jan 11 2011 Nov 01 2011 | 11 Jan 2011 01 Nov 2011 |
| 11203 | | Jan 12 2003 Nov 02 2003 | 01 Dec 2003 11 Feb 2003 |
| 112003 | | Jan 01 2003 Nov 20 2003 | 01 Jan 2003 |
| 201211 | 2012 Jan 01 | | 20 Dec 2011 |
| 2003123 | 2003 Jan 23 2003 Dec 03 | | |
The above is limited to near-current dates; with a wider date range, there are very many more cases.
To convert between longint and Roman numerals, see my test program cvt_rome.pas. It now also lists Roman numbers requiring more characters than any lower number; all of the Arabic numbers of the form "'1' or '2' or '3' or '8', followed by zero or more occurrences of '8'". (There is a four-function calculator and Roman date information at naturalmath.)
An American date typically uses MM-DD-YY or MM/DD/YY (a.k.a. FFF*). These, in a file, can be auto-corrected to YY-MM-DD or YYYY-MM-DD or (DD-MM-YY or DD-MM-YYYY) with MiniTrue (for DOS, Windows, and UNIX); SED can presumably also be used.
In DOS, this rectifies dates like 02-29-00 to 29-02-00
(mtr is the MiniTrue EXE) :-
C:\EPHEMERA>
mtr -x+ $$$$.txt - (\d\d)-(\d\d)-(\d\d) = \2-\1-\3
or vice versa.
The part including \d is a Regular Expression
(RegExp); RegExps are
known to many text-recognition and editing systems.
These (each on one line) in addition insert 19 or 20 (windowing into 1970-2069), converting MM-DD-YY to DD-MM-YYYY and YYYY-MM-DD respectively :-
C:\EPHEMERA> mtr -x+ $$$$.txt - (\d\d)-(\d\d)-([0-6]\d) = \2-\1-20\3 (\d\d)-(\d\d)-([7-9]\d) = \2-\1-19\3 C:\EPHEMERA> mtr -x+ $$$$.txt - (\d\d)-(\d\d)-([0-6]\d) = 20\3-\1-\2 (\d\d)-(\d\d)-([7-9]\d) = 19\3-\1-\2
For general use, a check on the previous and next characters might be added.
US governmental agencies also use YYYYDDMM (BRF), which can be rectified similarly.
See also in JavaScript Date and Time 9 : Output Formatting.
* : Fred Flintstone Format.
JavaScript Date.parse('01/02/03') is unsafe, because there is no guarantee that the author, any subsequent reader/amender, and all relevant software will all agree as to what it means, because of field order and Y2k problems. '2001/02/03' should be much safer; and new Date(2001, 1, 3) would be even better were it not for possible mistakes in month numbering (JavaScript uses 0..11).
For a GMT date string, new Date("YYYY/MM/DD GMT") is good.
For absolute time, msec = Date.UTC(2001, 1, 3) is unambiguous; use new Date(Date.UTC(2001, 1, 3)) to get a Date Object.
JavaScript accepts almost any value for any field of a Date (subject to the overall range), and adjusts the object's value accordingly; the value is evidently held as an integer-value IEEE Double of milliseconds. Setting "Feb 27, 60 hours" gives noon on Feb 29 or Mar 1. Beware of Summer Time changes.
Some JavaScript engines, but not all, accept some TLAs for Time Offset, and also the "military" letters. The only safe TLAs are GMT & UTC. It also accepts a.m., p.m., am, pm - which must not be abbreviated further.
See also JavaScript Date and Time, via which may be found an improved DATE Object.
Programs can store time and/or date information, internally or in files, in a multitude of formats; a few store the time as in MSDOS $40:$6C, and fewer the date as a count from 1980. See Zeroes of Date/Time Scales.
As above; also, on the Net, the RFCs include reliable, but ill-chosen, standards for writing date and time.
For more, see :-