- From: David Singer <singer@apple.com>
- Date: Tue, 10 Mar 2009 12:03:37 -0500
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). > >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. -- David Singer Multimedia Standards, Apple Inc.
Received on Tuesday, 10 March 2009 10:03:37 UTC