[whatwg] <time>

[Andy Mabbett]

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