- From: Robert J Burns <rob@robburns.com>
- Date: Thu, 12 Mar 2009 15:48:55 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Charles McCathieNevile <chaals@opera.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Bruce Lawson <brucel@opera.com>, whatwg@lists.whatwg.org, "public-html@w3.org" <public-html@w3.org>
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