Re: [whatwg] <time>

Hi David,

On Mar 13, 2009, at 11:19 AM, David Singer wrote:

> At 17:02  +0100 13/03/09, Leif Halvard Silli wrote:
>> I struggle to understand why it is better to ask *authors* to use  
>> One True Calendar instead of e.g having a scheme attribute through  
>> which the author can specify the date/time format.
>
> You might want to read <http://www.cs.tut.fi/~jkorpela/iso8601.html>  
> where it is stated "Automatic processing of data is easier to  
> program if dates and times are expressed in a uniform, preferably  
> fixed-length notation." Also, you might consider our own <http://www.w3.org/QA/Tips/iso-date 
> > and how much harder it might be to represent dates in other  
> calendar systems and languages (Japanese is given here) if the  
> source format could vary.

No one has suggested presenting dates in a non-uniform fashion. Rather  
we are suggesting that the uniform mode of expressing dates should  
also include alternate calendars. In particular this allows authors to  
be more specific and precise in the dates they specify. It also  
permits a more uniform encoding of dates (compared, say, to allowing  
years such as 0000 but leave the meaning up to the users, authors, and  
implementations).

> If your alternative format can be converted to other date systems,  
> it is highly likely it can be converted to 8601, and then it should  
> be at source.  If it can't be converted to other formats, it is way  
> less useful as an markup value.

The chief accomplishments of ISO 8601 is the ability to represent  
dates in a uniform manner and in defining the Gregorian calendar from  
1582 to 9999 in an unambiguous way. Beyond those dates it leaves  
things imprecise and ambiguous. We have an opportunity to extend this  
in ways more suitable for the _world-wide_ web, since most calendars  
share the same properties that ISO 8601 provides representation for.

> Can we drop this topic?  Apart from suggesting
> a) that the fully delimited date format be required (extended format);
> b) that year 0000 and before be allowed;
> c) that parsing the body text as 8601 may be dangerous if it's  
> notated the same way but not (possibly proleptic) Gregorian;

Apart from the topics we're actually disputing? :-) The issue of year  
0000 opens a can of worms. Negative numbers open a can of worms. Both  
of those issues create much more confusion than permitting something  
like Julian calendar dates and supporting other calendars.

The concerns that I don't hear you addressing here are that:

1) HTML is often hand-coded and so it places an undue burden on  
authors to convert non-Gregorian calendar dates to Gregorian calendars  
dates
2) Some dates in other calendars do not map in an unambiguous way to  
Gregorian calendar dates, but such dates would still benefit from  
machine readability and the unambiguous encoding (in the same way  
Gregorian calendar dates do).
3) ISO 8601 says nothing about the interpretation of non-positive  
years and so the meaning within ISO 8601 is left ambiguous without  
further normative criteria
4) Other cultures/locales use other calendars regularly in not only  
religious settings but also for official civil calendars
5) The lack of a calendar identification mechanism tends to lead  
authors to enter dates without an awareness of the calendar system  
used (i.e., allowing something like a prefix, suffix or separate  
attribute value for calendar dates can indicate a greater certainty  
that the date is entered correctly and guide authors in entering dates  
correctly) For example, authors may tend to incorrectly add a date  
such as "<time content="1917-11-7">11 November 1917</time>" and not  
even understand the issue of calendars (not a trained historian but  
likely other authors). With some other syntax, this error can be  
avoided (such as "19171107_Julian" or "19171025_Gregorian").

> otherwise we don't seem to have made much progress on 'improving'  
> this side-line in HTML, despite the rather large volume of posts.

However these are serious issues that HTML5 should address if we want  
it to support  the machine-readable encoding of dates. To me it would  
be better to drop the 'time' element than to leave it in the ambiguous  
and incomplete state it is currently in. I do think it would be good  
to create a summary of the thread on the wiki to chronicle these and  
other issues, but whether anything on the wiki[1] ever will be picked  
up by the editor is another question. Right now we have a draft that:  
1) doesn't even reference ISO 8601, 2) allows 0000 without attaching  
sufficient meaning to it and does not allow any further dates before  
0000, 3) does not clearly define the era, 4) and does not provide  
sufficient document conformance norms for the contents of the 'time'  
element.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/DateTime>, a very rough start to  
compile the issues discussed.

Received on Saturday, 14 March 2009 00:27:01 UTC