Re: [whatwg] <time>

(I thnk this is a permathread for the moment, so posting it to HTML as  
well for reference. Is there an issue raised for this, or whatever the  
method /du jour/ for identifying questions to be dealt with is?)

On Tue, 10 Mar 2009 01:36:33 +0100, Toby A Inkster  
<mail@tobyinkster.co.uk> wrote:

> It does seem to me to be a little foolhardy for HTML5 to be defining its  
> own format for representing dates and times. ISO 8601 is already widely  
> understood and implemented. Out of the box it is capable of representing  
> any instant[1] between 10000 BC and 9999 AD, including leap seconds and  
> any other edge case you choose to think about. Why reinvent the wheel?

In the same way that the W3C Date Time Format note did, it makes sense to  
profile ISO 8601 (which is monstrously big as well, and allows lots of  
different stuff). Indeed, referring to that (it is probably the most  
common format used in metadata communities, who are likely to be  
interested in using the element in the first place) would be a step  
forward.

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

Enabling these more complex use cases would resolve a lot of people's  
uneasiness over the limited utility of the current design. It would also  
make it easier to explain to communities who publish or hold large amounts  
of metadata how HTML 5 gives them a clear benefit.

An alternative approach of course would be to enable RDFa, since using RDF  
it is already simple to deal with these use cases, and the people who have  
them very often ahve their data in an RDF-compatible form already.

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 02:22:59 UTC