[whatwg] <time>

On Tue, 10 Mar 2009 18:03:37 +0100, David Singer <singer at 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 Tuesday, 10 March 2009 17:48:51 UTC