W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] time element use cases for less specific datetime values

From: Oli Studholme <whatwg.org@boblet.net>
Date: Fri, 20 Aug 2010 16:57:58 +0900
Message-ID: <AANLkTimgsBktnSZNRGkDanxJ5qTLdNEjDF-Pk=irBXug@mail.gmail.com>
Hi there,

I?d like to contribute to the discussion on the <time> element with
some use cases

On Thu, Mar 19, 2009 at 10:35 AM, Ian Hickson <ian at hixie.ch> wrote:

> The primary use cases for <time> are:
>
> ?* The ability to encode 80% of dates and times in a machine-readable way
> ? so that the user can make use of them in an automated fashion, in
> ? particular for adding dates to a calendar.
>
> ?* The ability to restyle dates that contain a "day" component so that
> ? they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000).
>
> ?* The ability to encode the output of <input type=date> and <input
> ? type=time> in an unambiguous fashion, for styling.
>
> None of these require that <time> be able to express years or year-month
> pairs; what are the use cases that we should address that need <time> to
> support these formats?

#1 Adding month or year (imprecise) dates to a calendar
I?m involved in organising events, and as part of this we make plans
for events with approximate times. Currently we use a shared calendar
plus have a list of events and approximate dates on a private website.
Rather than add a list of events to a web page plus add event data to
both a calendar, I?d like to list the events on a web page using
<time> and hCalendar or a microdata vocabulary, then add these events
to a calendar via a conversion tool. A workaround would be to use full
dates, but that gives a false indication of accuracy.

#2 Restyling dates
As others have already mentioned, in Japan it?s common to display
dates as 20-8-2010, 2010-8-20 and 2010?8?20?. In addition there?s this
fun alternative year system that?s still widely used, including in
official documents such as driver?s licenses, based on eras. Currently
it?s the 22nd year of the Heisei era; ?22?8?20?. As in Hixie?s example
of allowing dates to be restyled to follow user conventions, it would
also be very useful to allow this for year and year-month dates, as
even Japanese people have difficulty converting between the two
systems, especially for anything before they were born. Allowing year
and year-month @datetime values would allow a browser to offer
localisation of date display including conversion between these two
date formats. For example:
? ?<time datetime="1935">?9?</time>
could be automatically restyled to
? ?<time datetime="1935">1935</time>
(that?s the ninth year of the Sh?wa era btw ;)

Japanese credit cards frequently list only two digits for expiry year
(eg ?10/15?), and some Japanese e-commerce sites use a 2-digit input
for year. Confusingly (well initially for me) these are always the
abbreviated 4-digit year not the era year. Having this information
semantically notated would make it more accessible.

#3 Encoding <input> unambiguously
If this is a use case, it would be nice to be able to encode all the
datetime-related states of the <input> element. It?s not currently
possible to use <time> for month and week input states. It would also
be nice to have a year state for <input>, as it has more use cases
than week, and it would allow combining with the month state for e.g.
credit card info.

Finally, I?m not sure how much of a use-case this makes but I?d like
to use <time> with microformats and microdata. Not allowing more time
formats (year, year-month, month-day?) restricts the use of <time> to
vocabularies with year-month-day specific dates.

If these primary use cases have changed please let me know. Hopefully
some of these use cases will be relevant for allowing at least year
and year-month formats for @datetime, as per ISO 8601.

Thanks for your time

peace - oli studholme
Received on Friday, 20 August 2010 00:57:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC