W3C home > Mailing lists > Public > public-html-data-tf@w3.org > December 2011

Re: <time> values in HTML5

From: Toby Inkster <tai@g5n.co.uk>
Date: Sat, 3 Dec 2011 16:41:13 +0000
To: tantek@cs.stanford.edu
Cc: "John Cowan" <cowan@mercury.ccil.org>, "John Cowan" <cowan@ccil.org>, "Jeni Tennison" <jeni@jenitennison.com>, www-xml-schema-comments@w3.org, "HTML Data Task Force WG" <public-html-data-tf@w3.org>, "RDFa WG" <public-rdfa-wg@w3.org>, public-html-xml@w3.org
Message-ID: <20111203164113.46ece6cd@miranda.g5n.co.uk>
On Mon, 21 Nov 2011 09:51:07 +0000
"Tantek Çelik" <tantek@cs.stanford.edu> wrote:

> months and years durations were deliberately excluded due to
> 1. Lack of documented use-cases/publishing examples for them.
> 2. Precedent. Explicit exclusion of month and year durations from
> iCalendar (which was the basis for hCalendar, which was a key design
> driver for the time element).

I would posit that the use cases for <time> are a superset of those for

While one is unlikely to want to add the Hundred Years War to their
calendar, it might still be useful to mark up its duration with a <time>
element on a web page.

	<time value="P116Y">116 years</time>

seems infinitely preferable to

	<time value="P42340D">116 years</time>

which is not only unruly, but implies a level of precision that seems

ISO 8601 gives us a nice, standard notation for durations. I'd support
subsetting it if there were massive disadvantages to adopting the full
notation, but I don't think these disadvantages exist. I've written a
parser for ISO 8601 durations before, and I can't recall the
requirement to differentiate between 'M' before and after the 'T' being
especially onerous to implement.

Toby A Inkster
Received on Saturday, 3 December 2011 19:54:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:26 UTC