There's an historical precedent that argues in favor of expanding the datetime string.
Many calendar utilities limit the date domain to the UNIX one. Thus, entering an anniversary for a wedding that occurred prior to 1970 is the "kiss-of-death:" there is no way to determine just which anniversary is involved (silver anniversary, paper, ceramic...). A small item? Not to the gift card and gift industries. So an apparently trivial, supposedly non-business limitation had a big effect. Whether or not providing a means to specify dates before the Gregorian Reform or before the beginning of the first millennium will have a business effect is difficult to determine. One thing that can be said is that the applications which would be enabled certainly won't exist if the facilities are not present. Currently, the extreme datetime values (as opposed to the strings) can be specified in Javascript. Producing the corresponding datetime strings from such values should be mandatory. That argues in favor of proper "round trip" handling: the conversion of extreme datetime strings should be available too. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Cline Sent: Thursday, 2008 April 24 13:58 To: Lachlan Hunt Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Expanding datetime -----Original Message----- >From: Lachlan Hunt <[EMAIL PROTECTED]> > >Ernest Cline wrote: >> From a practical viewpoint, being able to specify dates before >> January 1, 1 BC (Gregorian) would allow for historical dates not >> currently available to be specified in markup of documents concerning >> history. > >Such dates do not need to be published on the web in machine readable >readable formats. How often to do you need to book a flight, or add an >event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±YYYY-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
