Time element

Summary: Research, data, use cases, issues, and enhancements related to the HTML5 time element (see also W3C TR time snapshot).

HTML5's new <time> element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.

The time element has been improved through the research done on this page. See:

• Time element: accepted proposals

Please read the following proposals for improving the <time> element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

Tantek (and other proposal authors).

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

All Date granularity proposals have been accepted. See: Time element accepted.

HTML5 internal consistency

impedance match new date time inputs

The proposal to impedance match new date time inputs was partially accepted (additional time element granularity). See: Time element accepted.

inputs to impedance match new time granularity

While this could be documented on an input element page, it made sense to keep it here as it's a part of time element discussion.

For each time element granularity, there should be a corresponding input element.

The time element should be able to represent every granularity of times and dates that the new date time <input> elements allow and vice-versa. 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">          - <time>YYYY-MM</time> (accepted as of 2011-11-18)
<input type="week">           - <time>YYYY-Www</time> (accepted as of 2011-11-18)
<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">           - <time>YYYY</time> (accepted as of 2011-11-18)
<input type="month-day">      - <time>--MM-DD</time> (accepted as of 2011-11-18)

The following input elements are proposed to represent the respective time element granularity:

• input type="year"
• input type="month-day"

Opinions / discussion:

• +1 Tantek
• +1 Andy Mabbett
• +1 Asbjørn Ulsberg
• ...

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-1600"[1]), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

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. Time periods in astronomy

building on the English Heritage Periods list and Timelines thesaurus - see Douglas Tudhope's mailing list post and prior discussion

3. http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list via Archaeological Periods list meta page - see Nick Boldrini's mailing list post

4 ...

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 Jérôme Beau provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :

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

  Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.

  <time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time>

• +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~"."
• +1 Asbjørn Ulsberg I like the concept, but the syntax should be less verbose and more precise.
  • "Circa" can be indicated with a tilde prefix "~"
  • Ranges can use ISO-8601 time interval syntax, like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
• 0 Lars Gunther One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
  • The proposal is to make such dates machine parsable. Pigsonthewing 09:54, 17 August 2010 (UTC)
• -1 Martin Janecke - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. Ocolon 12:54, 22 August 2010 (UTC)
  • It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say Bronze age. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". Pigsonthewing 22:34, 22 August 2010 (UTC)
    • I wrote "this doesn't seem to be well thought through yet", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the fuzzy date section be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. Ocolon 01:17, 23 August 2010 (UTC)
      • Done. Pigsonthewing 11:24, 23 August 2010 (UTC)
• ...

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.
• Documenting pre-Gregorian time travel in science fiction
  • Dr Who time travel
• See also various use cases under #Fuzzy dates, above for eras pre-dating the Gregorian calendar

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.
• 0 Martin Janecke - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
  • Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. Pigsonthewing 22:40, 22 August 2010 (UTC)
• +1 John Dalziel Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
• …

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.
• Dates before the Christian/Common Era could be specified by adding an era attribute that can take two values: CE (Common Era) or BCE (Before Common Era). If the attribute isn't present, then a default value of CE is assumed. The Dionysian "Common Era" doesn't have a "year 0" thus eliminating that potential issue.
  • See related: add era attribute to time element change proposal

Syntax improvements

permit space instead of T in datetimes

Status

2011-12-06 Adopted in WHATWG HTML.[5]

Summary

The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

summary of permit date-space-time

Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:

2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.

2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <time> element and the <ins> & <del> elements.

Inspired by the first part of this proposal by Marat Tanalin, with additional references/issues documented from #whatwg on 2011-12-01.

existing implementation support of date-space-time

Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:

• Python. The date time python module outputs " " instead of "T" for str(aDatetime).
• Perl. "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [6]
• MySQL. MySQL takes and sends all its dates in date-space-time format.
• postgresql "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [7]
• Javascript Date.parse method.
  • Chrome can parse it "2011-11-11 11:11:11".[8],[9]
  • Opera [10]
  • Notable exceptions that DO NOT parse it:
    • Firefox8 [11]
    • IE8 returns NaN[12]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[13]
      • also returns NaN for "2011-11-11T11:11:11"[14] - thus unclear that lack of space support is any kind of meaningful result.
    • IE9 returns NaN [15]
    • IE10 returns NaN [16]
    • Safari returns NaN for:
      data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script>

date-space-time issues questions

gratuitous departure from ISO8601

"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:

• it does help readability, incrementally
• we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

date-space-time discussion

Opinions / discussion:

• +1 Marat Tanalin per [17].
• +1 Tantek - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
• +1 kennyluck per [18]. "I think this [ISO8601-with-space] is the most i18n-wise human-readable format."[19]
• +1 mkanat per [20]
• +1 zewt "it's a natural, human format, where *T* really isn't" [21]
• ...

reducing DRY violations overview

We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).

This experience yielded the microformats adoption of the DRY principle - Don't Repeat Yourself - in application to (meta)dataformat designs and techniques.

The <time> element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [22]).

This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the <abbr> element.

Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related <abbr> problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).

http://microformats.org/wiki/value-class-pattern#Date_and_time_values

We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 <time> element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).

Accordingly, please consider the following <time> syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.

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.

In short, instead of this (actual example derived from markup of blog post HTML5 watch by Jeremy Keith)

<time class="published" datetime="2009-12-13T17:43:29">
  Sunday, December 13th, 2009
  5:43pm
</time>

We want to be able to do this:

<time class="published">
  <time datetime="2009-12-13">Sunday, December 13th, 2009</time> 
  <time datetime="17:43:29">5:43pm</time>
</time>

and have the parent <time> element composite a complete datetime from the child <time> elements with separate date and time.

The separate date and time datetime attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.

This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.

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 and related processing.

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.
  • Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - Tantek
    • [Belated response, as I stopped following this site a long time ago (not least because of the snide and derogatory tone of some comments, of which the above is a fine example), and only revisited by chance]. Had I said "international readability is irrelevant", you might have a point. I did not, and you misquoted me. I actually said (emphasis added for clarity) "'international' readability is irrelevant, when pages are otherwise in one language or another". While YYYY-MM-DD format is relevant in a-lingual contexts such as code and data, when a page is in a specific language then the prose date in that language is the most accessible to its target audience (An example would be the use of "24 November 2011" on this page. In your own signature). Making the date accessible to readers of other languages - especially at the cost of reduced accessibility for the target audience - is irrelevant, if the reader cannot understand the surrounding text. Nor do I "assume Western bias". In this case, what I said was "accessible prose such as, say, '5 August 2010' or 'August 5th, 2010'". Note the inclusion of the phrase "such as, say", which indicates that the following examples are just that: examples. I gave my examples in English, because discussion on this page is carried out in English. But what I said holds true if the date is written in Urdu, Mandarin, Arabic, Japanese, or any other specific language. I posit that 80% of the world do not use YYYY-MM-DD dates outside of special use cases such as those I mention; and still evidence to the contrary is lacking. Nor do I hold an "anti-internationalisation position" (assuming that is what you mean by the far from internationally accessible "i18n"). Once again, I must ask you not to attempt to speak for me. My objection stands. Andy Mabbett 11:49, 10 July 2022 (UTC)
• +1 Asbjørn Ulsberg - With nesting (and ISO-8601 time intervals), the hCalendar example can be made more precise and less verbose like so:

<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 datetime="2005-10-05/2005-10-07">
    <time class="dtstart">October 5</time>-
    <time class="dtend">7</time>
  </time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>

• • Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data farther from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). Tantek 19:39, 11 August 2010 (UTC)
  • In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. Tantek 01:31, 24 November 2011 (UTC)
• -1 User:cobaco We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:

to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)

• • Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. Tantek 01:31, 24 November 2011 (UTC)
• ...

am pm and coarser time parsing

Right now time values inside a <time> element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.

In short, instead of this (actual example derived from markup of blog post HTML5 watch by Jeremy Keith, with nested time elements per previous proposal)

<time class="published">
  <time datetime="2009-12-13">Sunday, December 13th, 2009</time> 
  <time datetime="17:43:29">5:43pm</time>
</time>

We want to be able to do this:

<time class="published">
  <time datetime="2009-12-13">Sunday, December 13th, 2009</time> 
  <time>5:43pm</time>
</time>

It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.

This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.

am pm syntax summary

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.

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)
    • Please do not rewrite or edit my comments. Andy Mabbett 11:51, 10 July 2022 (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.

The words "noon" and "midnight" may be specific to English (the language used on this page); the concepts are not. 00:00:00 is not "12am" and 12:00:00 is not "12pm". Andy Mabbett 11:55, 10 July 2022 (UTC)

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.

Other types of time

duration

Status

2011-11-18 Adopted in WHATWG HTML.

Summary

It would be great if the time element could support expressing durations as well for the use cases as needed by the hMedia and hAudio microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

• Allow for also parsing the following:
  • PnD,nH,nM,nS
    • where P, D, H, M, S are case-insensitive literals
    • P is optional
    • n is a fixed point number expressible with a decimal point
    • and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
  • PnDTnHnMnS (per informative reference: ISO8601 duration)
    • where P, D, T, H, M, S are case-insensitive literals
    • n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

duration examples

Typical bims are <time datetime="P61D">61 days</time> long.

(source: NewCalendar bim defintion)

"The Game Has Changed" <time datetime="P3M,25S">3:25</time>

(source: Wikipedia: TRON:Legacy soundtrack track listing)

Length <time datetime="P42M,59S">42:59</time>

(source: Wikipedia: The Dark Side of the Moon); existing markup is:

<tr class=""> 
<th scope="row" style="text-align:left;">Length</th> 
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td> 
</tr>

within an hAudio microformat.

The movie is <time datetime="96m">96 min.</time>

(source: IMDB:TRON)

duration faq

• Q: Why not re-use the literal ISO 8601 duration syntax?
  • A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
    • "," comma separated duration components (much more readable for humans)
    • dropping of the "T" between date and time components
    • reserve "Mo" standard abbreviation for Months for future disambiguation.

duration discussion

Opinions / discussion:

• +1 Tantek (proposer).
• +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
  • +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. Tantek 02:55, 15 July 2011 (UTC)
  • Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. Tantek 06:07, 18 November 2011 (UTC)
  • updated accordingly. Tantek 20:17, 4 November 2011 (UTC)
• +1 Andy Mabbett (Pigsonthewing) (as Wikipedia editor who deployed hAudio there; see Album template which uses Duration template)
  • Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. Tantek 06:07, 18 November 2011 (UTC)

• ...

Additional changes to consider:

• separate 'duration' attribute. It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
  • add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
  • permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
• fuzzy durations.
  • Jérôme Beau As per fuzzy dates mentioned above, durations should allow fuziness in durations :

    <time datetime="P1H" certainty="P5M">one hour, more or less five minutes</time>

    Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.

    <time datetime="P1H" certainty="P1M,P30S">one hour, up to 1 minute shorter or 30 seconds longer</time>

timezone

Status

2011-11-18 Adopted in WHATWG HTML.

Summary

It would be great if the time element could support expressing timezone as well for the use cases as needed by the hCalendar and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

• Allow for also parsing the following:
  • -HHMM
  • Z
  • +HHMM
  • Where -, +, and Z are literals.
  • Where HH is a two digit number (zero padded for values less than 10) that represents hours
  • Where MM is a two digit number (zero padded for values less than 10) that represents minutes
• And interpret the result as a timezone offset.

timezone examples

<code><time datetime=-0700>Pacific Daylight</time>

(source: [23] in reply to [24])

... more examples welcome (e.g. see [25] for extracting more)

timezone discussion

Opinions / discussion:

• +1 Tantek (proposer).
• ...

tz attribute

As quoted from the part of this proposal by Marat Tanalin.

Status

new

Summary

Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's contents, thus preventing authors from duplicating date partially or entirely in both contents and @datetime attribute.

The @tz attribute is optional."

tz attribute examples

<time tz="-8">2011-11-12 19:20</time>

tz attribute discussion

Opinions / discussion:

• +1 Marat Tanalin (proposer) per this proposal
• -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
• ...

Minor editorial fixes

Update hCalendar example

Status

2011-11-18 Fixed in WHATWG HTML. See also bug 14696.

Summary

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

Current example

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.

Updated example

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>: 
 <time class="dtstart" datetime="2005-10-05">October 5</time>-
 <time class="dtend" datetime="2005-10-07">7</time>,
 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)
• W3C Date and Time Formats discussion note
  • mailing list was [email protected]. - anyone have archives URL?
• 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)
• Dublin Core terms, e.g.
  • dcterms:temporal at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
    • example using dcterms:temporal
  • dcterms:created http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
• Time Ontology in OWL
  • Use a custom datatype or a property for approximate dates? - discussion of the above.