Re: [whatwg] <time>

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

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

> Supporting ranges seems to have a strong case for inclusion based on
> the current dates.  As Charles says, it's relatively common for
> current calendar events to take place over more than one day.  Making
> time apply only to single days renders us incapable of marking this up
> in a machine-readable way, which means that many common, current,
> real-world events can't be automagically imported into a calendar app
> appropriately.  The only possible current workaround, marking up the
> start and end dates, is *far* from optimal.
>
>
> (Supporting ranges would also give us support for lower-granularity
> dates automatically, though in a slightly less convenient to author
> manner.)

I agree. We should support ISO 8601 encoded ranges.

Take care,
Rob

Received on Thursday, 12 March 2009 20:49:35 UTC