- From: Charles McCathieNevile <chaals@opera.com>
- Date: Wed, 11 Mar 2009 01:48:51 +0100
- To: "David Singer" <singer@apple.com>, "Toby A Inkster" <mail@tobyinkster.co.uk>, whatwg@lists.whatwg.org
- Cc: "public-html@w3.org" <public-html@w3.org>
On Tue, 10 Mar 2009 18:03:37 +0100, David Singer <singer@apple.com> wrote: > At 3:22 +0100 10/03/09, Charles McCathieNevile wrote: >> That format has some serious limitations for heavy metadata users. In >> particular for those who are producing information about historical >> objects, from British Parliamentary records to histories of >> pre-communist Russia or China to museum collections, the fact that it >> doesn't handle Julian dates is a big problem - albeit one that could be >> solved relatively simply in a couple of different ways. > > The trouble is, that opens a large can of worms. Once we step out of > the Gregorian calendar, we'll get questions about various other calendar > systems (e.g. Roman ab urbe condita > <http://en.wikipedia.org/wiki/Ab_urbe_condita>, Byzantine Indiction > cycles <http://en.wikipedia.org/wiki/Indiction>, and any number of other > calendar systems from history and in current use). Then, of course, are > the systems with a different 'year' (e.g. lunar rather than solar). And > if we were to introduce a 'calendar system designator', we'd have to > talk about how one converted/normalized. > > I'd rather have the historical pages say "In the 4th year of the first > Indiction cycle of the second reign of the Emperor Justinian called the > golden-nosed, in the 3rd day following the nones of August, at the hour > of dawn in the city of Chrysopolis" (and then they give the Gregorian > translation, e.g. 6am on the 12th of August 707 CE). Indeed. That's one of the ways it can be done. IMHO it meets a huge set of the possible use cases. And it has the sort of simplicity that tends to be the defining characteristic of the best of HTML5. (Well, parsing isn't simple and is clearly part of the best of, but I am sure you get my drift...) >> The other issue is the one of precision - while you can name a single >> year, which will deal with a lot of use cases there are a lot left out >> because the precision required is a period. Ranges are included in >> 8601, and making a range syntax that handled almost all the relevant >> use cases is pretty straightforward. > > Adding a range construct to 8601, or having a range construct ourselves > using 2 8601 dates, seems like something we could ask for or do. Yep. Using a slash, as ISO 8601 does, strikes me as pretty simple and gives us compatibility. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Wednesday, 11 March 2009 00:49:43 UTC