andy at pigsonthewing.org.uk
Thu Mar 12 14:43:11 PDT 2009
In message <49B90C20.9040607 at lachy.id.au>, Lachlan Hunt
<lachlan.hunt at lachy.id.au> writes
>* Investigation of how imprecise dates affect the ability to import
> 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
> 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:
<abbr class="dtstart" title="2009-04-09">9</abbr>
<abbr class="dtend" title="2009-04-23"> 22 April 2009</abbr>
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
>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?
More information about the whatwg