Re: [whatwg] <time>

Hi David,

On Mar 13, 2009, at 7:37 PM, David Singer wrote:

> At 19:26  -0500 13/03/09, Robert J Burns wrote:
>> The chief accomplishments of ISO 8601 is the ability to represent  
>> dates in a uniform manner and in defining the Gregorian calendar  
>> from 1582 to 9999 in an unambiguous way. Beyond those dates it  
>> leaves things imprecise and ambiguous.
>
> You keep saying this, but I have yet to hear what is imprecise or  
> ambiguous.  Could you be more clear?
>
>> Apart from the topics we're actually disputing? :-) The issue of  
>> year 0000 opens a can of worms. Negative numbers open a can of worms.
>
> What can of worms?  In what way is labelling the day before 1 jan  
> 0001 as 31 dec 0000 unclear?

It's hard for me to demonstrate a negative. Can you quote some prose  
in HTML5 or ISO 8601 that makes it clear what that means. Does  31 Dec  
0000 refer to an actual date in the proleptic Gregorian calendar? Does  
it refer to 31 Dec 1BC in the proleptic Gregorian calendar? There's no  
prose in there that indicate what 00001231 means? Without knowing what  
00001231 means, we also do not know what -00011231 means. The same for  
every date prior. For comparison see the XSD datatypes note I cited  
earlier to see what an unambiguous specification looks like[1]  
(however keep in mind that the note I cite is non-normative but points  
to where the framers want XSD datatypes to go in the future).

>
>
>> 1) HTML is often hand-coded and so it places an undue burden on  
>> authors to convert non-Gregorian calendar dates to Gregorian  
>> calendars dates
>
> so it's better to place that burden on the many readers rather than  
> the one writer?  I don't follow you.

No. I'm suggesting it is better to place that burden on the  
implementations. Again, I'm not suggesting adding to the default  
burden of implementations since I'm arguing UAs should only be  
required to support Gregorian dates (ignoring any unsupported  
calendars). For authors that want to ensure widespread UA support they  
will still need to convert the dates to Gregorian. For authors  
targeting UAs that have richer calendar support, they need only  
include the native calendar date they're referencing (for example  
directly citing a Hebrew calendar date rather than converting it first  
to Gregorian). The approach I'm advocating is simply more flexible and  
more appropriately abstracted for a specification such as HTML. We  
aren't trying to get the down and dirty minimial requirements to build  
a web page. We're speccing HTML for global use.

>> 3) ISO 8601 says nothing about the interpretation of non-positive  
>> years and so the meaning within ISO 8601 is left ambiguous without  
>> further normative criteria
>
> It says it uses consecutive integers as year labels, allows a minus  
> sign, and, in case you are in any doubt, has an example of year  
> 0000. What is ambiguous?

It says it requires further agreements to use those dates. The reason  
it requires those further agreements is not merely to have two parties  
say: "hey should we support other years?", "Yeah, sure". The point is  
that further criteria need to be specified to define what 0000 and  
lower means. Similarly for years with digits greater than four, the  
norms included in ISO 8601 are insufficient to unambiguously specify  
such dates. Both situations require further specification of norms.  
That's fine. HTML5 could specify those. But you and others have been  
arguing against other calendar support by suggesting we should just  
use ISO 8601 as is (which loses dates outside the range 1582 - 9999).

>> 1) doesn't even reference ISO 8601,
>
> I agree that would be better.
>
>> 2) allows 0000 without attaching sufficient meaning to it
>
> ?
>
>> and does not allow any further dates before 0000,
>
> yes, the reason for this prohibition is unclear, as they are well- 
> defined.

They may be well defined. They are not well defined in any of the  
normative references we've identified. They may also be easily  
extrapolated once the representation 0000 is well-defined. However,  
that is not well-defined either.

If I ask you to encode the date 14 February 1BC, what does that look  
like in ISO 8601? I would say it could be either 00000214 or -00010214  
depending on the supplemental norms needed to use dates before year  
0000.

>> 3) does not clearly define the era,
>
> 8601 does, or do you mean something else?

ISO 8601 does not clearly define whether a proleptic Gregorian  
calendar includes 0000 or whether the sequence of years goes:  -1 (1  
BC), 1 (AD 1). In other words does 0000 refer to 1 BC/BCE or does it  
refer to the year zero? I would say the former (and perhaps you would  
too), however that's not specified in ISO 8601 or any other  
specification available to us (XSD Datatypes is heading in that  
direction). Even if we do clearly specify this, I predict it will  
often trip up authors. I know of no way around that, except to try to  
be as clear as we can as the framers of the specification.

Again what ISO 8601 does well is provide an unambiguous representation  
of  a date with years, months, and days. This is a set of  
representations for properties shared by nearly all calendars.  
However, ISO 8601 does not clearly and unambiguously define a  
Gregorian calendar for all possible dates. So I've been suggesting we  
can use something very much like ISO 8601 for multiple calendar  
support and I'm trying to help you and others understand that we  
cannot use ISO 8601 alone to specify a complete Gregorian calendar (in  
particular dates before 1582, after 9999, and acutely due to the  
ambiguity of non-positive integer years and years with more than four  
digits).

Take care,
Rob

[1]: <http://www.w3.org/TR/xmlschema-2/XSD#year-zero>

Received on Saturday, 14 March 2009 01:19:47 UTC