[whatwg] <time>

1582? No, no no...

If we're going to implement <time>, please stay with the current specifications (epoch being year 0001) rather than further limit
the tag's usefulness and/or engender more controversy.

Other than that, I agree that this thread has just about run its course, trampled the garden, mowed through the fields, and
otherwise acted like Godzilla on an "urban renewal kick." It's why I wrote many many days ago, "It won't die!"

Cheers!
BdG
-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Smylers
Sent: Saturday, 2009 March 14 04:35
To: whatwg at lists.whatwg.org; public-html at w3.org
Subject: Re: [whatwg] <time>

Robert J Burns writes:

> Hi David, On Mar 13, 2009, at 11:19 AM, David Singer wrote:
> 
> > Can we drop this topic?  Apart from suggesting
> > a) that the fully delimited date format be required (extended 
> > format);
> > b) that year 0000 and before be allowed;
> > c) that parsing the body text as 8601 may be dangerous if it's 
> > notated the same way but not (possibly proleptic) Gregorian;

This thread appears to be proving that dates are very complicated and that to get them right for the general case involves lots of
subtleties, which would be a reason for punting -- only doing the simplest possible thing for now, acknowledging that that doesn't
meet all desirable scenarios, and leaving everything else for HTML 6.

Even attempts to produce a small list of changes that we have consensus on yields others disputing them, showing that we don't have
consensus.

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

Smylers

Received on Saturday, 14 March 2009 04:59:21 UTC