Re: [whatwg] <time>

Hi Tab,

On Mar 12, 2009, at 3:58 PM, Tab Atkins Jr. wrote:

> On Thu, Mar 12, 2009 at 3:48 PM, Robert J Burns <rob@robburns.com>  
> wrote:
>> Hi Tab,
>>
>> On Mar 12, 2009, at 12:51 PM, Tab Atkins Jr. wrote:
>>
>>> At this point, I think I'm in strong agreement with two points, that
>>> of allowing negative years and of allowing a range.
>>>
>>> Allowing negative years is so trivial on the parsing side as to make
>>> it somewhat ridiculous that it's not supported.  The use-cases for a
>>> full year-month-day in BC times are fairly small, but they do exist,
>>> and so for the nearly nonexistent cost of implementation I think  
>>> we'd
>>> be doing a disservice not allowing this.  (The uses for negative  
>>> years
>>> increase substantially if either ranges or lower-granularity dates  
>>> are
>>> supported as well.)
>>
>> The problem with adding support for BC is we need to supplement ISO  
>> 8601
>> with another specification or our own normative criteria. I'm not  
>> speaking
>> against that, I think it is worthwhile, but I just want to be clear  
>> about
>> the problems. Non-normative portions of ISO 8601 imply that a zero  
>> year
>> should also be included which is a controversial step. It may be  
>> better to
>> include negative years, but not a zero year. Or to indicate that  
>> every
>> non-positive year in ISO 8601 actually indicates a year-minus-one  
>> in the
>> proleptic Gregorian calendar. In this way the simple leap year  
>> rules apply
>> correctly to the years as they are used in the Common Era (and  
>> specifically
>> BC/BCE).
>
> I'm not much concerned about the debate over year 0; as has been
> stated earlier in the thread, we're not date experts here.  As long as
> we can get a clear answer out of ISO 8601, I'm happy with going with
> that.

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. So either we go with your first proposal and supplement ISO  
8601 with norms to cover BC or we take ISO 8601 as is and only support  
1582 to 9999.

>  Whether or not to allow a year 0 is so far from an important
> issue it isn't funny.  Worst case, the spec allows it but it
> represents nothing.  I don't see this as a problem.

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).

>> I also think we could add support for longer years by requiring the  
>> use of
>> hyphens whenever a year exceeds four digits. So 20090311 would be
>> acceptable, but 10,000 years from now would have to be represented as
>> 12009-03-11.
>
> I'm not sure that is necessary to really worry about supporting.  But
> hey, is it really necessary to add hyphens?  Is 120090311 ambiguous?
> Is it just the lookahead issue?  (You'd have to read the entire date
> string before you could be sure which part was year, month, and day.)

The issue arises because ISO 8601 supports other date formats that  
together with years greater than five digits create ambiguity. For  
example: "2009108". Is this the year 20091 and the eighth day? Or is  
is the year 2009 and the 108th day? By prohibiting certain ISO 8601  
representations we could indeed eliminate the need for hyphens and  
still support years with greater than four digits.

>> Supporting Julian calendar dates also appears to be equally low- 
>> hanging
>> fruit (or even lower) since such dates representations share  
>> everything in
>> common with Gregorian dates (only the leap year rules are simpler  
>> and simple
>> automated conversions before about 4AD are probably ill-advised).
>
> This I still completely disagree with.  You want to write dates in the
> Julian calendar on your page?  Feel free!  That doesn't affect
> anything.  We're talking about handling a machine-readable form of
> data.

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. 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? 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.

Take care,
Rob