Re: [whatwg] Fwd: <time>

Hi Aryeh,

On Mar 15, 2009, at 6:59 PM, Aryeh Gregor wrote:

> On Sun, Mar 15, 2009 at 6:30 PM, Tom Duhamel  
> <tom420.duhamel@gmail.com> wrote:
>> What about those 'other calendars of concern'? Are they reasonably
>> compatible with Gregorian, or so much different that my example of  
>> the Mayan
>> long count becomes a good one? I know nothing about those, but I  
>> fear it's
>> the later.
>
> You're correct.  For instance, the Jewish calendar has 12 months of 29
> or 30 days, except that sometimes it has 13 months, and it only syncs
> up with the Julian calendar every 19 years, except sometimes when it's
> off by a day, and the algorithm for calculating whether months have 29
> or 30 days depends on when the new moon will hypothetically first be
> visible in Jerusalem according to an astronomical model that was
> finalized early in the first millennium CE, plus also on when certain
> holidays would fall out in the coming year.
>
> I don't know much about the other calendars, but they're similarly
> unrelated to the Gregorian calendar, for sure.  Apparently, some
> variants of the Islamic calendar aren't even planned out in advance --
> you literally have no idea whether the current month is going to be 29
> days or 30 until it's actually announced based on observation of the
> new moon, and different Muslim countries decide it differently.  There
> are variants that allow the start of Islamic months to be calculated
> in advance, but there seem to be several different ones.
>


However, in terms of the question Tom poses – which is much more about  
calendar date representation – the dissimilarity of the Mayan Long  
Count calendar is not shared by most other calendars. Most calendars –  
in contrast to the Mayan long count – can be represented in terms of  
years, months and ordinal days of the month in exactly the way that  
ISO 8601 handles Gregorian date representation. Even the Mayan Long  
Count calendar can be represented in something resembling ISO 8601 by  
allowing more than the three fields for the date (e.g.,  
"12-19-16-03-03t19:57+00:00").

To say that calendars do not match up except at certain times is the  
same as saying they are different calendars (like saying that a metric  
and US measuring tape only match at the origin). Many calendars try to  
match their year to the tropical solar cycle but even the Gregorian  
does not lead to the tropical events occurring precisely at the same  
time each year (I've heard arguments about whether the equinox is on  
the 21st or the 20th of the month when the point is it drifts within a  
certain range).

Astronomy also tells us that the length of the tropical cycle itself  
changes over time so treating the Gregorian as the more accurate (or  
calculation as superior to observation) is a little like celebrating  
the amazing atomic-clock-like precision of a broken clock that occurs  
each day. On the other hand, though the Islamic calendar is not a  
tropical solar calendar, in terms of representation it still involves  
years (potentially more than 4 digits), months (two digits), and days  
(two digits) just like the Gregorian and these other calendars (note  
the Julian calendar requires something like 445 days for one  
particular year, but that still doesn't push the limits of the ISO  
8601 date representation approach as none of the months exceed 99 days  
and the months also remained below 99). Again, HTML UAs can easily  
allow the representation of these various calendar dates without  
imposing any requirement burden on UAs to support conversion and  
extraction of these alternative calendar dates (merely a requirement  
to recognize calendar keywords and ignore unsupported calendars; in  
the case of Julian the ISO-8601-style representation translates to the  
exact same localized month names from 44 BC onward).

So support for representing dates in multiple calendars does not have  
to include support for converting among dates. Specialized UAs (or  
even specialized web services) might provide facilities to perform the  
conversion. In terms of HTML we only need to concern ourselves with  
date representation. In addition I think many UAs will need to support  
extraction of Gregorian dates (though again other UAs might allow  
extraction and conversion of alternative calendar dates). There's a  
reluctance to force implementors to perform conversion between  
alternative calendar dates. OK fine. But let's not make authors  
convert those dates either simply to make use of a feature to  
unambiguously encode the date in a machine readable form. Let's allow  
that feature to support dates even without conversion (especially  
since we're merely looking for an unambiguous uniform approach to  
encoding dates and not conversion, extraction, comparison, etc.).

Take care,
Rob

Received on Monday, 16 March 2009 11:33:24 UTC