ross@spam.ua.oz.au (Ross Williams) (06/22/91)
CRIT_006: FORMAT OF DATE ------------------------ From: gordoni@berlioz.ua.oz (Gordon Irlam) Date: 22 Jun 91 11:01:26 GMT From article <859@spam.ua.oz>, by ross@spam.ua.oz.au (Ross Williams) | [A meta standard for data compression.] | |> Date string - A date string is a standard string of length 11 having |> the format "dd-mmm-yyyy" where dd is in the range "01".."31", mmm |> is in the range "Jan","Feb",.."Dec" (Case dependent), and yyyy is |> in the range "1900" and "9999". | |Hence, | | 20-Jun-1991 | |But this creates yet another incompatible date/time format. It would |be better to adopt a standard date/time format. | |A fairly common date/time format on the Internet is that used in |RFC 822. It looks something like this. | | 20 Jun 91 15:48:18 GMT | |Unfortunately this date/time format has several disadvantages: | | - It contains "white space" characters. | | - Even without the white space the mapping from literal strings to | date/times is many to 1. | | - The representation of the month only makes sense in English | speaking countries. | | - It doesn't include the century. (What will happen to Usenet on | the 1st of January 2000?) | |It would probably be better to choose one of the following. | | 1991-06-20 | | 1991-06-20T15:48:18Z | |These are the "extended format complete representation of a calendar |date", and the "extended format complete representation of a moment of |Coordinated Universal Time" as specified by ISO 8601. | |Advantages of the yyyy-mm-dd format over the widely used dd-mm-yyyy |format include: | | - "The avoidance of confusion in comparison with existing national | conventions using different systems of ascending order." | | (the U.S. national format is easily confused with that of most | other countries) | | - "The ease with which the whole date may be treated as a single | number for the purposes of filing and classification." | | (ie. sorting) | | - "The possibility of continuing the order by adding digits for | hour-minute-second." | |Note that ISO 8601 includes representations for many other date/time |quantities that are not relevant here. These include yyyy-ddd and |yyyy-Www-d formats, basic formats, reduced precision, truncated |representations, fractional hours, minutes, and seconds, periods of |time, and time zone differences. | |It would be a serious mistake to allow any ISO 8601 date/time format |since writing a program to parse an arbitrary ISO date/time |representation would be a big challenge. Instead adopt just one |possible representation. (I would suggest the second of the two |formats presented above.) | | Gordon Irlam. | (gordoni@cs.adelaide.edu.au) I'm sold! However, I don't think that it is necessary to record the exact universal time of day at which an algorithm is released. The local date should be sufficient. No one will be able to work out what the universal time is anyway. Unless others disagree strongly, I propose to use the first format yyyy-mm-dd as a local date (i.e. you put in the date wherever you are in the world at the time when you release the algorithm) where all the letters represent ascii decimal characters in the range '0'..'9'. If the net gets like a patent office, the standard can be tightened to the second format. Thanks Gordon for sorting out that detail. I will keep this information up my sleeve for other projects too. Ross Williams ross@spam.ua.oz.au
emv@msen.com (Edward Vielmetti) (06/29/91)
iso 3309 (?) would be even better for dates. for one, it's already planned to be used in NNTP version 2. it'll also be used in the "archive normal format" for comp.archives descriptions of where things are. it's entirely numeric, very easy to parse. example. 19910102200501.34 is 02 Jan 1991 20:05:01.34 --Ed