[whatwg] <time>

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


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

~TJ

Received on Thursday, 12 March 2009 10:51:47 UTC