A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Time element: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(→‎duration discussion: Additional changes to consider)
(→‎duration: permit MM:SS and HH:MM:SS syntaxes for a 'duration' attribute)
Line 573: Line 573:
* '''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:
* '''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.
** 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.
</div>
</div>


Revision as of 06:17, 18 November 2011

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.

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

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

year only

The time element should accept just a year.

ISO8601 syntax
YYYY

year only use cases

use case research:

  • http://microformats.org/wiki/birthday-examples#year_only
  • use cases in VCARDDAV & EDTF - see external links
  • Wikipedia 'Start date' template - thousands of YYYY instances
  • Wikipedia infobox with YYYY birthdate (unknown MM-DD)
  • Copyright notices are often year-only; e.g. that at the foot of [1]
  • In biological taxonomy, a species', genus' or other rank's authority (the person who named it, and the year they did so) always includes a whole-year date value. For example:
    • Barn Owl, Tyto alba (Scopoli, 1769) [2]
    • Strigiformes (Wagler, 1830) [3]
  • Photo date taken
  • Citations from a bibliography which list two or more works by the same author disambiguate them by year
  • Commerce
    • "a piece of jewellery hallmarked 1933"
    • "a 1973 Chevy"
  • Sport
    • 2008 Olympics
    • 1966 World Cup
  • Awards
    • "1973 Oscar for best film"
    • "1988 Nobel Peace Prize"
  • Restyling dates for localisation and to follow user conventions
    • 2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
  • Relative dates in texts: news websites and blogs often use phrases such as
    • "damages during last year's Gaza offensive" [4],
    • "recession next year almost inevitable" [5]

year only discussion

Opinions / discussion:

  • +1 Faruk (per Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01") One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <time> element only allows for datetime values as precise as a specific day, e.g. YYYY-MM-DD.
  • -1 Hixie - "Without clear use cases, I don't intend to change the spec here." (ibid)
  • +1 Tantek (per HTML5 Super Friends Technical Details: time element)
  • +1 Andy Mabbett (Per use cases in VCARDDAV & EDTF - see external links)
  • +1 Philip Jägenstedt - for marking up release dates on e.g. MusicBrainz where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.
  • +1 Asbjørn Ulsberg - for marking up years on Wikipedia ("...global military conflict lasting from 1939 to 1945...").
  • +1 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 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: email to WHATWG
  • +1 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 drublic - As input-fields support `year` the datetime-attribute as it is (was until ) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
  • ...

year only related posts

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

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

    hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?

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

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

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


year month only

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

ISO8601 syntax
YYYY-MM

year month use cases

  • Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
  • output equivalent of <input type="month">, see impedance match new date time inputs.
  • use cases in VCARDDAV & EDTF - see external links
  • Wikipedia 'Start date' template - thousands of YYYY-MM instances
  • Photo date taken
  • Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
  • Restyling dates for localisation and to follow user conventions
    • 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
  • Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
    • "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [6]
    • "George W. Bush leaves office in January next year" [7]

year month discussion

Opinions / discussion:

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

year month related posts

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

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

    hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?

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

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

  • 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time blog post by Bruce Lawson:

    I suggest the spec be amended to allow dates like "July 1966"

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

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

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

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

  • 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 [sic] 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″.

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 <input type="week">, see impedance match new date time inputs above.
reasoning
to provide the output equivalent of <input type="week">

See impedance match new date time inputs above.

Opinions / discussion:

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

month day only

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

ISO8601 syntax
--MM-DD
use case research
http://microformats.org/wiki/birthday-examples#month_and_day_only
use cases discussed in VCARDDAV & EDTF - see external links
Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.

Opinions / discussion:

HTML5 internal consistency

impedance match new date time inputs

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

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

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

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

Opinions / discussion:

Proposals extending scope

Fuzzy dates

The time element should accept fuzzy (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and 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."[8]
Implemented, see [9], (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 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 . 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 [10] - 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
  • 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)
  • …

Calendar scale related posts

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

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

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

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

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

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

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

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

Syntax improvements for reducing DRY violations

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. [11]).

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

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

am pm example with nested time elements

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

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

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

am pm discussion

Opinions / discussion:

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

am pm FAQ

noon and midnight

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

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

am pm i18n

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

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

Other types of time

duration

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.

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
  • And interpret the result as a timezone offset.

timezone examples

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

(source: [12] in reply to [13])

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

timezone discussion

Opinions / discussion:

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

Minor editorial fixes

Update hCalendar example

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

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

Resources

Retrieved from "https://wiki.whatwg.org/index.php?title=Time_element&oldid=7700"