Time element

Research, data, use cases, issues, and enhancements related to the HTML5 time element.

year only

The time element should accept just a year.

ISO8601 syntax

YYYY

use case research

http://microformats.org/wiki/birthday-examples#year_only

Opinions / discusion:

• +1 Faruk (per Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01") One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <time> element only allows for datetime values as precise as a specific day, e.g. YYYY-MM-DD.
• -1 Hixie - "Without clear use cases, I don't intend to change the spec here." (ibid)
• +1 Tantek (per HTML5 Super Friends Technical Details: time element)
• +1 Andy Mabbett (Per use cases in VCARDDAV & EDTF - see external links)
• +1 Philip Jägenstedt - for marking up release dates on e.g. MusicBrainz where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.
• ...

year month only

The time element should accept just a year and a month.

ISO8601 syntax

YYYY-MM

Opinions / discusion:

• +1 Faruk (per Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01") One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <time> element only allows for datetime values as precise as a specific day, e.g. YYYY-MM-DD.
• -1 Hixie - "Without clear use cases, I don't intend to change the spec here." (ibid)
• +1 Tantek I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/
• +1 Andy Mabbett (Per use cases in VCARDDAV & EDTF - see external links)
  • Portable contacts allows this using a "0000" year value.
• +1 Philip Jägenstedt - for marking up release dates on e.g. MusicBrainz where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.
• ...

month day only

The time element should accept just a month and a day.

ISO8601 syntax

--MM-DD

use case research

http://microformats.org/wiki/birthday-examples#month_and_day_only

Opinions / discusion:

• +1 Tantek (per HTML5 Super Friends Technical Details: time element)
• +1 "radiz" implied support for --MM-DD with the use case question: "How to use <time> with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/
• +1 Andy Mabbett (Per use cases discussed in VCARDDAV & EDTF, e.g. birthdays, wedding anniversaries - see external links)

Calendar

The time element should accept a calendar scale (default is GREGORIAN) per the emergent vCard 4 specification, to facilitate the mark-up of non-Gregorian (e.g. Julian) dates.

Opinions / discussion:

• +1 Andy Mabbett (Per use cases in VCARDDAV & EDTF - see external links)
• ...

Fuzzy dates

The time element should accept fuzzy (uncertain, approximate) dates and eras.

Opinions / discussion:

• +1 Andy Mabbett (Per use cases in "Extended Date Time Format" proposals - see external links)
• ...

Specification ambiguities

Nowhere does the specification say times and dates should be in the ISO-8601 format. Failure to say if, and to what extent that specification is adopted leads to ambiguities such as:

• Is 20100701 a valid date?
• Is 1972-06-30T23:59:60 a valid date & time?

The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date implies that ISO-8601 is not adopted, since that date has no special significance within the ISO 8601 spec.

Choose different default date

The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.

A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.

External links

• Extended Date Time Format efforts based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)
  • EDTF proposals (use-cases)
• Dates and coordinates in HTML5 - blog post by Andy Mabbett
  • Feb 2009 whatwg mailing list discussion of the above
• vCard Format Specification draft-ietf-vcarddav-vcardrev-11 (latest draft as at July 2010)
  • Section 4.3, date & time
  • Section 5.7, CALSCALE (specifies Gregorian or other (e.g. Julian) calendar)
    • VCARDDAV discussion of CALSCALE
• ISO 8601 (Wikipedia article)