- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 12 Mar 2009 12:51:47 -0500
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Bruce Lawson <brucel@opera.com>, whatwg@lists.whatwg.org, "public-html@w3.org" <public-html@w3.org>
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 17:52:23 UTC