Time element

2010-08-26T08:57:02Z

Myrrhman: /* Resources */

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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,

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

=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
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* 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) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
*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" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "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><time></code> element only allows for <code>datetime</code> 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 [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)
* +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.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [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 month only ==
The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* 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." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month 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><time></code> element only allows for <code>datetime</code> 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 [[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:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)
* +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#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +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.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [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/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</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://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</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 <time> 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 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><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== 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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use <time> with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

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

<pre><nowiki>
<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
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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:
** 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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|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. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|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. [[User:Ocolon|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 <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|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 [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 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:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 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)
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [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 <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.</blockquote> 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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

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

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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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: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>
<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></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)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

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

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?

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

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

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

= Minor editorial fixes =

== Update hCalendar example ==

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

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples 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:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]

== Resources ==

* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[http://www.mac-how.net More Info]

WHATWG Wiki - User contributions [en]

Time element