Re: [whatwg] <time>

Hi Chaals,

On Mar 10, 2009, at 7:48 PM, Charles McCathieNevile wrote:

> 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...)


Moving to a common calendaring system is important for comparing dates  
and perhaps searching for events in a uniform manner. However, it  
actually places a burden on authors to shoehorn dates into the  
Gregorian calendar and in terms of UTC when they would otherwise be  
expressed in some other calendar (or where UTC makes no sense  
whatsoever).

>>> 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.

I think that's fine for ranges. However, though David used the term  
ranges, I more get the impression he was discussing something more  
like precision, accuracy, or deviation. As I said earlier I think such  
deviation would be helpful both for date data and geocoding data. For  
e geocoding example, often times a location will be flagged based on  
the center of a zip code. The difference in deviation is very relevant  
to a user compared to a deviation based more in terms of meters or  
centimeters. Likewise if an event is to happen at an ISO 8601  
specified date time, it is relevant to a user whether that date time  
is specified in terms of give or take a few milliseconds or give or  
take a month. Since these data types get used in widely disparate  
situations, such information is even more important.

Take care,
Rob

Received on Wednesday, 11 March 2009 01:12:13 UTC