HTML5's new &lt;time&gt; 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.

HTML5's new &lt;time&gt; 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.

−

However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.

+

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

+

* [[Time element accepted|Time element: accepted proposals]]

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

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

−

Thanks for your consideration,

Thanks for your consideration,

[[User:Tantek|Tantek]] (and other proposal authors).

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

−

−

=== year only discussion ===

−

<div class="discussion">

−

Opinions / discussion:

−

* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 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 <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.

* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.

−

* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").

−

* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.

−

* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]

−

* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.

−

* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.

* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

−

−

=== year only next steps ===

−

Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

−

−

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 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 <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.

* +1 [[User:Tantek|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 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.

* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.

−

* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]

−

* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.

* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>

* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>

* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote>

−

−

=== year month next steps ===

−

Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

−

−

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

−

−

== 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 <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

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

−

== 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 <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)

* +1 [[User:Javarome|Jérôme Beau]] provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :<pre><nowiki><time datetime="1855-06-18" certainty="P3D">around 18 June 1855</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time></nowiki></pre>

* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)

* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)

* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:

* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:

Line 261:

Line 120:

* 0 [[User:Ocolon|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.

* 0 [[User:Ocolon|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. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)

**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. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)

+

* +1 [[User:crashposition|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.

* …

* …

</div>

</div>

Line 269:

Line 129:

* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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

* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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

* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

+

* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.

: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 <code>&lt;time></code> element and the <code>&lt;ins></code> &amp; <code>&lt;del></code> elements.

+

+

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #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:

* '''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 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]

+

* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html 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 [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]

* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]

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).

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).

Line 410:

Line 327:

* +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 [[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 [[User:Pigsonthewing|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.

* -1 [[User:Pigsonthewing|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. - [[User:Tantek|Tantek]]

* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:

* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:

<pre><nowiki>

<pre><nowiki>

Line 421:

Line 339:

</div></nowiki></pre>

</div></nowiki></pre>

** 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 <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)

** 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 <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|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. [[User:Tantek|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:

+

<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> 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. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)

* ...

* ...

</div>

</div>

Line 517:

Line 439:

= Other types of time =

= Other types of time =

== duration ==

== duration ==

−

It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

* '''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'''.

+

** [[User:Javarome|Jérôme Beau]] As per fuzzy dates mentioned above, durations should allow fuziness in durations :<pre><nowiki><time datetime="P1H" certainty="P5M">one hour, more or less five minutes</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="P1H" certainty="P1M,P30S">one hour, up to 1 minute shorter or 30 seconds longer</time></nowiki></pre>

</div>

</div>

== timezone ==

== timezone ==

−

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

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

As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime 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 <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

* -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.

Latest revision as of 12:32, 26 November 2014

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:

Date granularity

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)

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.

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)

"...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.

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)

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.)

Calendar scale discussion

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

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.

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.

Syntax improvements

permit space instead of T in datetimes

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.

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).

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).

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:

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:

check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)

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)

use the complete contents of the <time> element as its datetime value.

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:

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:

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

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:

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)

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

<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.

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 faq

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:

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.

timezone

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

timezone discussion

tz attribute

"@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

-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

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.

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.