Time element

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

Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the Miscellaneous proposals section.

Date granularity

year only

The time element should accept just a year.

ISO8601 syntax

YYYY

year only use cases

use case research:

• http://microformats.org/wiki/birthday-examples#year_only
• use cases in VCARDDAV & EDTF - see external links
• Wikipedia 'Start date' template - thousands of YYYY instances
• Wikipedia infobox with YYYY birthdate (unknown MM-DD)
• Copyright notices are often year-ony; e.g. that at the foot of [1]

year only discussion

Opinions / discussion:

• +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 only related posts

Related posts (listed with quotes directly related to year only) :

• 2009-02-25 HTML 5, politics and me blog post by Bruce Lawson - look for mention of "time element" which mentions:

  I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec

year month only

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

ISO8601 syntax

YYYY-MM

year month use cases

• Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
  • http://www.flickr.com/photos/tantek/archives/
  • whatwg's own mailing list archives (!)
• output equivalent of <input type="month">, see impedance match new date time inputs.
• use cases in VCARDDAV & EDTF - see external links
• Wikipedia 'Start date' template - thousands of YYYY-MM instances
• Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)

year month discussion

Opinions / discussion:

• +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)
• +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 related posts

Related posts (listed with quotes directly related to year-month) :

• 2009-02-25 HTML 5, politics and me blog post by Bruce Lawson - look for mention of "time element" which mentions:

  I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec

• 2009-08-20 HTML 5: what’s hot, what’s not blog post by Bruce Lawson - see section on TIME which explicitly mentions:

  The time element is still hamstrung by not being able to markup ... dates like “December 1935″

• 2009-08-30 HTML5 and me blog post by Jeremy Keith - see section on "time" which explicitly mentions

  make a piece of information like “April 1912” machine-readable

year week only

The time element should accept just a year and a week number.

ISO8601 syntax

YYYY-WNN

use case research

no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.

output equivalent of <input type="week">, see impedance match new date time inputs above.

reasoning

to provide the output equivalent of <input type="week">

See impedance match new date time inputs above.

Opinions / discussion:

• +1 Tantek per good design of impedance matching date time inputs.
• ...

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

use cases discussed in VCARDDAV & EDTF - see external links

Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.

Opinions / discussion:

• +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)
  • Portable contacts allows this using a "0000" year value.

HTML5 internal consistency

impedance match new date time inputs

The time element should be able to represent every granularity of times and dates that the new date time <input> elements allow. Here is a list of all the date time <input> elements along with the corresponding <time> element usage (if applicable)

<input type="date">           - <time>YYYY-MM-DD</time>
<input type="datetime">       - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month">          - not supported in current time element
<input type="week">           - not supported in current time element
<input type="time">           - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year">           - not supported in current time element
<input type="month-day">      - not supported in current time element

In particular the <time> element is missing support for the following date inputs:

• input type="month" - this would be satisfied by the time element year month proposal.
• input type="week" - this would be satisfied by the time element year week proposal.

In addition, if the new proposed input elements are accepted, the respective time element support should be added as well:

• input type="year" - this would be satisfied by the time element year proposal.
• input type="month-day" - this would be satisfied by the time element month day proposal.

Opinions / discussion:

• +1 Tantek
• +1 Andy Mabbett
• ...

Proposals extending scope

Fuzzy dates

The time element should accept fuzzy (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".

Use cases

1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[2]

Implemented, see [3], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.

2. ...

Opinions / discussion:

• +1 Andy Mabbett (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
  • Uncertainty possibly resolved by a "certainty" attribute:

    <time datetime="1855-06-18" certainty="3days">around 18 June 1855</time>

    <time datetime="1970-06" certainty="45days">summer 1970</time>

    (with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or:

    <time datetime="1963-12" certainty="circa">circa December 1963</time>

    with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
• +1 Jim O'Donnell (Dates such as 'circa 1910' published on Flickr eg. The RNVR Training Ship 'Buzzard'… also a list of fuzzy dates for a set of photos.)
• 0 (comments) Tantek - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:
  • certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)
  • certainty attribute takes an ISO8601 duration.
  • alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)

    • <range><time>2001</time>-<time>2003</time></range>

• +1 Bruce Darcus says: "[While] I definitely think the use case is important...
  • "...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current draft idea in EDTF of doing "2000?" or "2000~"."

Calendar scale

The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the emergent vCard 4 specification, to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.

Calendar scale example

Example:

<time datetime="1330-06-01" calscale="julian">1 June 1330</time>

Calendar scale processing

User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)

Calendar scale use cases

Use case research:

• The Wikipedia timeline example in HTML5 Super Friends Technical Details: time element proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to pre-Gregorian era events, usually using the Julian calendar, such as the birth and death of Julius Ceaser and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [4] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)
• Julian dates in timeline of Georgia:
• General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.

Calendar scale discussion

Opinions / discussion:

• +1 Andy Mabbett (Per use cases in VCARDDAV, EDTF & TEI - see external links)
• 0 Tantek - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case does appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
• …

Calendar scale related posts

Related posts (listed with quotes directly related to Calendar scale) :

• 2009-02-23 Dates and coordinates in HTML5 blog post by Andy Mabbett -

  The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.

• 2009-02-25 HTML 5, politics and me blog post by Bruce Lawson - look for mention of "time element" which mentions:

  I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec

  BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale
• 2010-02-09 The time element (and microformats) blog post on HTML5 Doctor by Bruce Lawson - mentions:

  The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.

  Again, seemingly implying a desire for non-Gregorian calendars as well.

Syntax improvements for reducing DRY violations

composite nested time elements

A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.

This is intended as a cleaner way to provide functionality equivalent to the microformats value-class-pattern date and time values pattern.

background

Currently the <time> element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart"
        datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.
</p>

Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).

microformats value class pattern DRY advantage

With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <span class="dtstart">
     <span class="value">18:00</span> on 
     <span class="value">2010-08-05</span>
  </span>.
</p>

Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.

Disadvantage: the loss of the HTML5 time semantic.

simple nested time example improvement

We'd like to have our time and date time separation as well, so this should work:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart">
     <time>18:00</time> on 
     <time>2010-08-05</time>
  </time>.
</p>

summary of updated datetime algorithm

In short: the algorithm for determining the "datetime" of a time element should:

1. check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
2. check for nested <time> elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)
3. use the complete contents of the <time> element as its datetime value.

Essentially, step 2 is added to enable composing nested child time elements.

applicability to microdata

All of the aforementioned advantages for microformats apply to microdata use of the <time> element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).

nested time example with datetime attribute

If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart">
     <time>18:00</time> on 
     <time datetime="2010-08-05">August 5th, 2010</time>
  </time>.
</p>

Advantage: The advantage here over the current time element is that the DRY violation is limited to only the date information (instead of date and time information), thus reducing the risk of data divergence due to duplication.

nested time example with two datetimes

If the publisher prefers to publish a "localized" form of times, they can do that as well:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart">
     <time datetime="18:00:00">6pm</time> on 
     <time datetime="2010-08-05">August 5th, 2010</time>
  </time>.
</p>

Advantage: The two separate 'datetime' attributes (containing just the time and just the date) are more human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.

The AM/PM proposal below further helps improve this example.

nested time discussion

Opinions / discussion:

• +1 Tantek - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.
• -1 Andy Mabbett - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) Update: Subsequent changes have addressed some of my concerns. The proposal to separate times from dates with datetime attributes is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.
• ...

am pm and coarser time parsing

Right now time values inside a <time> element are required to specify hours in 24 hour time.

In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).

In short, the current <time> element only allows for the following time syntax:

• HH:MM:SS - where HH is in 24 hour time.

am pm syntax summary

This proposal expands the allowed time syntax to:

• HH:MM:SSam
• HH:MM:SSpm
• HH:MMam
• HH:MMpm
• HHam
• HHpm

am pm syntax details

• periods, white-space, case-insensitivity. "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").
• implied 00 minutes and seconds. When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;
• handling of 12am and 12pm. "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).

simple am pm example

A simple example:

I went to the cafe at <time>6pm</time>.

Advantage: by specifying am and pm times that can be parsed directly from the contents of the element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

am pm example with nested time elements

Example (uses aforementioned composite nested time element proposal as well)

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart">
     <time>6pm</time> on 
     <time>2010-08-05</time>
  </time>.
</p>

Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.

am pm discussion

Opinions / discussion:

• +1 Tantek - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 <time> element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.
• 0(query) Andy Mabbett - see above for concerns over date formatting.
  • queries moved to am pm FAQ section with answers. - Tantek 16:57, 6 August 2010 (UTC)
• ...

am pm FAQ

noon and midnight

Question: How does this cater for "noon" and "midnight", and the ambiguity over "12am" and "12pm"?

Answer: This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.

am pm i18n

Question: How does this internationalise "am" and "pm", for languages which do not use them?

Answer: For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.

Minor editorial fixes

Update hCalendar example

Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

The HTML5 spec currently has this hCalendar example:

<div class="vevent">
 <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
  <span class="summary">Web 2.0 Conference</span>:
  <time class="dtstart" datetime="2007-10-05">October 5</time> -
  <time class="dtend" datetime="2007-10-20">19</time>,
  at the <span class="location">Argent Hotel, San Francisco, CA</span>
 </div>

(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)

This appears to have been copy/pasted from a past version of the hCalendar spec that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

Here is a suggested update:

<div class="vevent">
 <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
 <span class="summary">Web 2.0 Conference</span>: 
 <abbr class="dtstart" title="2005-10-05">October 5</abbr>-
 <abbr class="dtend" title="2005-10-07">7</abbr>,
 at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see dtend issue for details).

Miscellaneous proposals

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.

Opinions / discussion:

• 0 (comment) Andy Mabbett - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?
• -1 Tantek - I don't see any other default date as being significantly different.
• ...

Issues without specific proposals

Specification ambiguities

The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.

Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.

See Also

• input - the input element, related proposals expanding upon the new datetime inputs.

External links

Tag

Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time

Prior discussion

• Dates and coordinates in HTML5 - blog post by Andy Mabbett
  • whatwg mailing list discussion of the above, Feb 2009
  • further whatwg mailing list discussion of the above, Mar 2009
  • Another mailing list thread Mar 2009
  • Spec editor's response to the above threads and further discussion, late Mar 2009
• 2009-11-26 Use cases for the time element whatwg email by Jeremy Keith
• HTML5 Doctor: The Time Element

Resources

• 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)
• 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
• TEI dates, widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates
  • TEI dates+times
• ISO 8601 (Wikipedia article)
• Proleptic Gregorian calendar (Wikipedia article)