From WHATWG Wiki

Jump to: navigation, search

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

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

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

• Time element: accepted proposals

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

Thanks for your consideration,

Tantek (and other proposal authors).

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

Date granularity

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

HTML5 internal consistency

impedance match new date time inputs

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

inputs to impedance match new time granularity

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

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

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

<input type="date">           - <time>YYYY-MM-DD</time>
<input type="datetime">       - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month">          - <time>YYYY-MM</time> (accepted as of 2011-11-18)
<input type="week">           - <time>YYYY-Www</time> (accepted as of 2011-11-18)
<input type="time">           - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year">           - <time>YYYY</time> (accepted as of 2011-11-18)
<input type="month-day">      - <time>--MM-DD</time> (accepted as of 2011-11-18)

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

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

Proposals extending scope

Fuzzy dates

The time element should accept fuzzy (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580-1600"[1]), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

Use cases

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

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

2. Time periods in astronomy

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

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

Calendar scale

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

Calendar scale example

Example:

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

Calendar scale processing

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

Calendar scale use cases

Use case research:

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

Calendar scale discussion

Calendar scale related posts

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

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

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

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

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

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

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

  Again, seemingly implying a desire for non-Gregorian calendars as well.
• Dates before the Christian/Common Era could be specified by adding an era attribute that can take two values: CE (Common Era) or BCE (Before Common Era). If the attribute isn't present, then a default value of CE is assumed. The Dionysian "Common Era" doesn't have a "year 0" thus eliminating that potential issue.
  • See related: add era attribute to time element change proposal

Syntax improvements

permit space instead of T in datetimes

Status

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

Summary

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

summary of permit date-space-time

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

2011-12-06T13:28:00

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

2011-12-06 13:28:00

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

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

existing implementation support of date-space-time

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

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

date-space-time issues questions

gratuitous departure from ISO8601

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

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

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

date-space-time discussion

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

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