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.
