Re: [whatwg] <time>

On Mar 16, 2009, at 8:49 AM, Mikko Rantalainen wrote:

> Smylers wrote:
>> Robert J Burns writes:
>>> Right now we have a draft that: 2) allows 0000 without attaching
>>> sufficient meaning to it
>>
>> I don't think that's the case; the algorithm for parsing a year  
>> requires
>> a number "greater than zero":
>>
>>  http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#parse-a-month-component
>>
>> So my suggestion for a spec change is to replace "zero" with "1582".
>> That further reduces the set of dates that <time> can represent, but
>> avoids the complexity of pre-Gregorian dates, and avoids  
>> inadvertently
>> giving a meaning to them that hampers the efforts of a future  
>> version of
>> HTML to do all of this right.
>
> Just remove the rule "If year is not a number greater than zero,  
> then fail."
>
> The objective, if I've understood correctly, is to be able to markup a
> specific time. Proleptic Gregorian calendar is suitable for  
> specifying a
> moment of time before 1582 without a doubt. The only thing that must  
> be
> *exclicitly* defined is whether or not the day before 0001-01-01 is
> 0000-12-31 or not. I think that it should be. If it is, it immediately
> follows that year "-6" is same as "7 BC" and I cannot see any problem
> with that. The "BC" is different unit so there can (and should) be an
> offset compared to unitless year number.
>
> If you cannot accept Proleptic Gregorian calendar because you believe
> that it cannot be defined exactly enough, then another possible choice
> would be the POSIX time (number of seconds since 1970-01-01 00:00:00
> UTC). Make that floating point number with arbitrary precision and it
> can specify any moment in the history or in the future. If less than  
> one
> second precision is needed, require author to always specify range in
> that case. Really simple to implement and definitely exact enough.
>
> Different calendar systems and daylight saving times are only methods
> for displaying or describing specific moments of time. The only thing
> required for HTML is *a method* for marking up any specific moment of
> time. I repeat: primary objective is to markup any specific moment and
> secondary objective is to make markup easy enough for the authors (I
> believe that the unix timestamp is not acceptable because it cannot be
> authored without using software aids). I do not believe that marking  
> up
> a given moment with multiple different methods should be an objective.


I think this is the crux of the misunderstanding. While ISO 8601 and  
Unix time constitute two methods that both represent dates in a  
uniform manner (which can presumably be mapped to Gregorian and even  
other calendars), this is NOT analogous to the differences in the  
various calendars. While ideally the various calendars should  
represent dates unambiguously convertible from one calendar to  
another, this is not the case. The conversion of dates is up for  
debate in historical, anthropological and theological circles (among  
others). So by forcing all dates into a converted Gregorian form, we  
are forcing authors to lose data when they encode a date in HTML. I  
don't see any reason we should force authors to encode lossy dates.  
Implementations may convert the encoded dates from one calendar to  
another for presentational purposes or to make comparisons between  
dates, but we should provide authors a lossless way to encode those  
dates.

We need to keep in mind the separation of dates in a persistent data  
storage sense from their interpretation by users and user agents. ISO  
8601 and Unix time both provide means to do the former, but both must  
be combined with calendar specifications to be complete (though ISO  
8601 also includes a specification for a Gregorian calendar from 1582  
to 9999). It is far easier for us to allow ISO-8601 style  
representation of dates from alternative calendars (using a keywords  
to differntiate), then it is for us to actually specify the various  
calendars used throughout the World and throughout history (especially  
since those using those calendars would not recognize us as the  
authority for that). Also we want to ease the burden on authors  
whenever possible. Unix time is an excellent example of a method that  
would increase the burden on authors (usually requiring a lookup or a  
calculation while ISO 8601-style representations will typically allow  
off the top of an authors head authoring).

[[allow alternate calendar representations without conversion helps  
ease the burden on authors and helps decrease the number of errors]]


Take care,
Rob

Received on Monday, 16 March 2009 19:48:15 UTC