Re: [whatwg] <time>

Hi David,

On Mar 12, 2009, at 6:57 PM, David Singer wrote:

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

I don't follow the distinction you're making here.  These sound the  
same to me in the current context.

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

These examples are from the non-normative sections of the spec. The  
norms make it clear that ISO 8601 does not take a position on dates  
before 1582. This suggests to me there was dispute in the creation of  
ISO 8601 that never permitted it to make normative statements about  
the proleptic Gregorian calendar (or they deemed it out of scope too).

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

No, I can't think of a reason to forbid it, but we should use caution  
in unambiguously specifying the document conformance. I've been  
arguing for expanding support. But we can't leave it as vague as the  
current draft does. We have to likewise (like ISO 8601) leave it to  
future standards (or mutual agreement though I think such language is  
less appropriate for the HTML5 draft) to determine comprehensively  
what the value means: but we should open it up to support other dates,  
eras, and calendars.

>> 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've said before, they are free in terms of data representation  
because date representation is identical for Gregorian and Julian  
dates. Date comparison on the other hand might require more from  
implementations. However, that more is also required in dealing with  
year zero and BC dates which cost you seem unconcerned with. It  
requires specification beyond ISO 8601 as well.

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

You're assuming the UA has to convert or compare the date. What use  
case are you thinking about here? If the UA merely has to display the  
date, then nothing more is required to support Julian dates when  
Gregorian dates are already supported (even conversion for many – but  
not all – Julian dates is trivial for implementations).

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

I don't think its appropriate to mix human readable content that  
comments on the machine readable attribute like that. Most users would  
wonder what the prose referred to there and the machine reading the  
date would ignore the prose. Why even require the author to convert  
the date? Why not simply allow the author to indicate in the  
attributes that the date is from a specific calendar and leave it at  
that? However a separate prefix, keyword or attribute to indicate the  
calendar would make the machine readable values completely unambiguous.

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

However, I have suggested requiring UA support ONLY for Gregorian,  
while allowing UA support for other calendars. So my proposal does not  
add any implementation cost whatsoever. However it does address the  
needs of authors by allowing them to encode dates in alternate  
calendars. If a UA does not support a calendar, then the UA can know  
to ignore the date and not treat it as Gregorian. However, if we fail  
to address the issue, there's likely to be more content produced with  
dates that are not Gregorian, but which UAs, authors and users assume  
are Gregorian. Something like that will lead to even more problems. We  
shouldn't hide the fact from authors that different calendars exist.  
Such 'simplification' only complicates things when authors then fail  
to provide a calendar qualifier for their dates.

I think it is better for us as framers of a specification to consider  
the Gregorian approach as one among many and abstract the  
specification accordingly. This might even be done by requiring a  
prefix before the ISO-8601-style date to indicate the calendar.  
Without the prefix, the UA has to resort to heuristics to determine if  
the date is Gregorian or otherwise know to not presume a specific  
calendar. Keep in mind that many authors will not know any more or  
even as much about the dates they encode here than those of us  
discussing it here. So they may not even know the date needs  
converting. We don't want UAs to assume it can treat the date as  
Gregorian, do we?

Take care,
Rob

Received on Friday, 13 March 2009 01:03:46 UTC