- From: Andy Mabbett <andy@pigsonthewing.org.uk>
- Date: Thu, 12 Mar 2009 21:43:11 +0000
- To: whatwg@lists.whatwg.org, public-html@w3.org
In message <49B90C20.9040607@lachy.id.au>, Lachlan Hunt <lachlan.hunt@lachy.id.au> writes >* Investigation of how imprecise dates affect the ability to import >such > events into a calendar. e.g. The Sydney Royal Easter show scheduled > for 2009-04, and takes place over a period of a few weeks in the > month. Is it enough to simply say: > ><time datetime="2009-04">9–22 April 2009</time> > > Or would it be better to give the precise date range, as > ><time datetime="2009-04-09">9</time>–<time datetime="2009-04-22">22 >April, 2009</time> > > Or would supporting a range directly in the datetime field support > this better: > ><time datetime="2009-04-09/2009-04-22">9–22 April 2009</time> > >Investigating how hCalendar currently addresses use cases like that >would be useful in order to address some of the limitations that >approach may have. The most common way of representing that date-range in hCalendar at present would be: <span class="vevent"> <abbr class="dtstart" title="2009-04-09">9</abbr> - <abbr class="dtend" title="2009-04-23"> 22 April 2009</abbr> </span> Note: A class="summary" is also required. The end date must be 'exclusive' - a known problem, for which solutions have been proposed. >Another case for an imprecise date might be: > ><p><time>2009</time> is The International Year of Astronomy.</p> > >For this, we would need to understand what real benefit consuming >applications would gain from that. It's not really a date that someone >would want to import directly into their calendar. But understanding >what other potential applications, such as those mentioned above, might >want to do with it would be useful. Yet again; the use-cases of sorting, searching or displaying visually (e.g. on a timeline). >> What advantage is there for authors and consumers by *not* extending >>the range of dates that can be described with <time> ? > >That's the wrong question to ask because it places the burdon of proof >on the wrong side. OK: What /dis/advantage is there for authors and consumers by extending the range of dates that can be described with <time> ? >But by not addressing every possible little use case under the sun, we >keep the language simplified and easier for authors to learn and use, If you re-read my original proposal, I suggested defaulting to Gregorian time, while allowing those authors who wish to, to specify Julian or other dates. >and we can focus on really optimising for the top ~80-90% of the use >cases, without spending a disproportionate amount of time trying to >optimise for the remaining ~10% of edge cases too. Who wants to fail ~10-20% of the time? -- Andy Mabbett
Received on Thursday, 12 March 2009 21:45:22 UTC