Re: [whatwg] <time>

Hi David,

On Mar 10, 2009, at 12:03 PM, David Singer 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).

I think there are several calendars worth considering, but these  
topics you list here are more examples of other related topics and not  
specifically calendars dates. ab urbe condita is simply an era system  
and not a calendar system. Having dates able to handle multiple era  
systems and abstracting that as a separate plane from calendar date  
greatly simplifies the process. ISO 8601 does not require a specific  
era system so another specification/criterion would need to supplement  
such information.

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

In practice all of the calendar years I am familiar with are tropical  
years – neither solar/sidereal nor lunar. In other words, whether the  
calendar is solar/sidereal or lunar the years are adjusted so that the  
seasons/equinoxes/solstices line up. Or, like the Gregorian calendar,  
the calendar is tropical from the start (expecting the days in a year  
to match the number of days between vernal equinoxes). Unfortunately  
the calendars also generally rely on different estimates for the  
number of days between tropical events (like the Julian at 365.25 and  
Gregorian at 365.2425). The actual number of days between tropical  
events varies over thousand-year cycles due to the gyration of the  
Earth.

Another important thing to consider is whether we require markup to  
support multiple calendars or whether only presentation needs to  
support multiple calendars. For example HTML5 could support gregorian  
calendar dates only (though less ambiguously than today). However, CSS  
and other presentation layers could support the presentation of those  
dates in any calendar system desired by users and supported by  
implementations. Once we have the dedicated semantics of the 'time'  
element or the RDFa 'datatype' attribute, it can be left up to CSS or  
implementations to present those dates however the user chooses – in  
whatever calendar system, era, time zone, etc. the user desires.

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

By separating presentation and semantics, you and every other user can  
tailor the presentation just as you like it. A user in Saudi Arabia  
may be fluent in English but still prefer to see dates presented in an  
Islamic calendar. A historian might prefer to see dates presented in  
the calendar specific to an cultural/historical event (such as the  
October revolution presented in the Byzantine calendar rather than in  
November in the Gregorian calendar) while an astronomer might prefer  
to see the date presented always as Gregorian dates (even for cultural/ 
historical events).

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

I've long felt that both dates and geocodes need some other parameter  
to express precision. This would not be in the sense of ranges as you  
suggest nor as a probability distribution since that's not quite what  
we're looking for but closely related. Instead it would be a parameter  
expressed in time (seconds, minutes, hours, days; distance for  
geocodes) that indicated that with some degree of certainty (say 95%)  
the date fell within the plus or minus range of this parameter. So  
when I say something will happen next week (from today 2009-03-10) it  
might be expressed as:

date: 2009-03-19t00:00z
precision: 3 days
percentile: 0.95

Which would indicate that the expectation should be that something  
like 95% certainty that the event occurs within that interval. If I  
know something will happen next week I could change the percentile to  
'1'.

Something similar for geocodes could indicate how accurate the geocode  
represented so a longitude/latitude pair might include a precision of  
5 meters or 4 kilometers. The percentile might be 1 in both cases,  
indicating that the author knew with certainty that the relevant  
location was included within the distance radius with the geocode as  
the center.

Take care,
Rob

Received on Tuesday, 10 March 2009 19:01:47 UTC