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

Re: [whatwg] <time>

From: Robert J Burns <rob@robburns.com>
Date: Thu, 12 Mar 2009 19:04:26 -0500
Cc: Geoffrey Sneddon <foolistbar@googlemail.com>, David Singer <singer@apple.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>
Message-Id: <8166DC57-BFA7-45B7-9084-D4A44658E6EE@robburns.com>
To: Julian Reschke <julian.reschke@gmx.de>
Hi Julian,

On Mar 12, 2009, at 11:53 AM, Julian Reschke wrote:

> Geoffrey Sneddon wrote:
>> ...
>> Ultimately, why is the Gregorian calendar good enough for the ISO  
>> but not us? I'm sure plenty of arguments were made to the ISO  
>> before ISO8601 was published, yet that still supports only the  
>> Gregorian calendar, having been revised twice since it's original  
>> publication in 1988. Is there really any need to go beyond what ISO  
>> 8601 supports?
>> ...
> Indeed.
> We aren't the subject matter experts on calendars and date formats,  
> so why do we pretend we are?

Let us keep in mind that the HTML5 draft does not reference ISO 8601.  
It also already reaches way beyond ISO 8601 and claims to handle dates  
all the way back to 0000-01-01 whereas ISO 8601 only handles dates  
between 1582 and 9999. So HTML5 already takes on the task of  
specifying dates beyond ISO 8601 and steps into heavily disputed  
territory by including one more year  the year before AD 1  in the  
proleptic Gregorian calendar.

On the other hand, many of the suggestions being made are much less  
controversial and are also calling for greater reliance on ISO 8601  
(however expanded or enhanced) and other future standards.

I think an easy way to make room for future standards to guide this  
and ease the burden on authors is to allow for a modestly expanded /  
enhanced ISO 8601 that supports alternatives (but does not specify  
precisely what those alternatives are). The default would be for a  
date to represent either an unspecified calendar or the Gregorian  
calendar, but with another mechanism to provide additional specifics  
(such as a 'calendar' attribute or reuse of the RDFa 'datatype'  
attribute). Similarly specifying a default era that only includes  
positive integers would allow us avoid the issues of whether a  
proleptic Gregorian calendar should or should not have a year zero  
(something which the current HTML5 draft takes a position on despite  
your suggestion that we are not the calendar standard specifiers).  
Another standard could then define one or more eras that provided  
Gregorian support for BC/BCE years (for example, one era with and one  
era without a year zero). RDFa 'datatype' attribute keywords could  
then be used to unambiguously express the calendar and era of the date  
associated with a 'time' element.

As I've said before, we know that most calendars can be handled by the  
ISO 8601 style of date representations:  1) years of 4 digits or more;  
2) months with two digits (generally 01 to 12 or 13); 3) ordinal dates  
within months of two digits (generally 01 through 31, but almost  
always less than 99). So not only is it fairly trivial to expand ISO  
8601 to support Gregorian dates beyond 9999 and before 1582, it is  
equally trivial to allow it to encode a date from any calendar sharing  
those three properties. Even adding a "J" or "MJ" prefix to an ISO  
8601 date (or through a separate accompanying attribute) could signify  
the integer 2009 referred to a Julian Day or Modified Julian Day  
(respectively) and not the year 2009. We don't need to be experts on  
these calendars; we merely need to provide sufficient mechanisms  
within HTML5 to allow authors to differentiate one from the other in  
an unambiguous manner.

Take care,
Received on Friday, 13 March 2009 00:05:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:43 UTC