Re: [whatwg] <time>

At 20:11  -0500 10/03/09, Robert J Burns wrote:
>>
>>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).

Well, not shoehorn:  translate if they can.

<time datetime="...ISO 8601 string...">Hasan of the blacksheep being 
Khan two years, in the month of the collection of walnuts, the third 
day after the full moon</time>
-- the author worked out when this was (good for them).

Leave off the attribute, and you're saying it's a time and the author 
could not (or did not) translate it.

I think this is what the draft says, to be honest.  Get it from the 
attribute if it's there, try to get it from the content, and if that 
fails, the date is unknown.

The only possible downside with the current drafts are:
a) there is no attribute to say what the content format is.  But 
until someone comes up with a uniform descriptive set of tags for the 
possible date formats, I'd leave this alone.
b) if the content is not a Gregorian proleptic date, and yet can be 
parsed as such, and the datetime attribute is absent, then the user 
may be misled.

I wonder why the 'try to parse the content' step is in there?


-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Wednesday, 11 March 2009 17:24:37 UTC