[whatwg] <time>

At 16:24  -0500 12/03/09, Robert J Burns wrote:
>That was my point: we cannot get a clear answer out of ISO 8601. ISO 
>8601 only covers dates between 1582 and 9999 without supplemental 
>norms.

No, it says mutual *agreement*, not supplemental norms.  ISO 
8601:2004 seems perfectly clear that the year before 0001 is 0000, 
and that -0002-04-12 means "The twelfth of April in the second year 
before the year [0000] " (example directly from ISO 8601).  The HTML 
spec. can constitute such agreement.

I see no reason to forbid such uses in HTML.  Can you?

>If we're only interested in the representation of dates - and not 
>their comparison - then I would agree with what you say here. 
>However, then supporting Julian dates are available for free (since 
>there are absolutely no differences in the representation of a 
>Julian date and a Gregorian date).

They are nothing like free if you want UAs to support them.

>
>As I said above this seems inconsistent with your position on year 
>zero. If we're only interested in date representations and not in 
>date comparisons then supporting Julian dates requires no more 
>implementation support than supporting Gregorian dates.

No.  If my UA wants to present dates to the user in his preferred 
form or calendar system, it helps iut enormously if there is only one 
way to represent a date, from which it has to convert.  If there are 
two, and the conversion of the second is a pain (which Julian is), 
this is a problem.

>However, if we're interested in comparing dates within a machine 
>readable attribute than it is very important how year zero and other 
>non-positive years are handled. I'm not trying to say gotcha here, 
>I'm trying to understand how you see these machine readable dates 
>being used. Are we interested in only date representation or also in 
>date comparison?
>
>>I don't think there is any legitimate reason to add support for
>>multiple calendars in the timestamp.  It's bad enough that we have
>>*two* competing time formats (the current spec format and unix
>>timestamps) for encoding dates over the wire.  Just convert your date
>>into the supported timestamp format, then represent it however you
>>want within your page.
>>
>
>However, this places a burden on authors that could be more easily 
>handled by implementations. When an author cites a historical date 
>they are often interested in it as the Julian date. Why should an 
>author need to go convert the date to Gregorian date every time the 
>author wants to use this HTML feature?

So the UA can display it.  If they don't care, leave off the datetime 
attribute.  If you are unsure of the conversion, say so in the text:

<date datetime="0707-04-04>Two days after the new moon of the 
festival of Artemis, Alexis the Orphanotropos visiting Philadelphia 
[conversion to Gregorian date is the best estimate of the 
translator]</date>

>Especially if date representation is the goal and not date 
>comparison, there should be no reason an author cannot use the same 
>ISO 8601-style representations for Julian dates.

Representation is a minor issue.  Definition of the name "julian", of 
the valid values of the attribute, and of the calendar "julian", are, 
and the cost to UAs of implementing it.
-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Thursday, 12 March 2009 16:57:35 UTC