W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: [whatwg] <time>

From: Leif Halvard Silli <lhs@malform.no>
Date: Fri, 13 Mar 2009 20:29:00 +0100
Message-ID: <49BAB3FC.5090101@malform.no>
To: David Singer <singer@apple.com>
CC: Julian Reschke <julian.reschke@gmx.de>, Geoffrey Sneddon <foolistbar@googlemail.com>, Charles McCathieNevile <chaals@opera.com>, Toby A Inkster <mail@tobyinkster.co.uk>, whatwg@lists.whatwg.org, "public-html@w3.org" <public-html@w3.org>
David Singer 2009-03-13 17.19:
> 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." 

So, it really is for comparison purposes that you want this 
feature. (Jukka Korpela speaks about e-mail exchange basically, 
where almost everything happens behind the scenes.)

For history texts, the automatic processing needs some third 
factor if by "automatic processing" you include accessibilty.

@datetime doesn't solve the ambiguous date issue if it can't solve 
the Julian date issue.

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

<time datetime=iso8601> will help circumvent those advices. And 
basically, that page does not have any advice for history texts.

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

Since you repeat this, it must also be repeated that this is more 
flat out than 8601 is. One should not use 8601 before 1582 without 
prior agreement, is what 8601 itself says. Or else you will 
confuse many parties. It is even confusing to use it for dating 
events in many countries up until the 20th century. This is were 
the ISO8601 approach fails.

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

   d) scheme attribute through which authors can specify the format

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

Regarding c): There have been many proposals to solve that. To 
make progress on that, I think we need some concessions/proposals 
from that side in the debate that thinks ISO8601 is the solution 
to everything. For instance, it can be solved by a mathematical 
factor [1]

[1] http://www.w3.org/mid/49BA67BF.2030409@malform.no
leif halvard silli
Received on Friday, 13 March 2009 19:30:05 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:45 UTC