WHATWG Wiki - User contributions [en]

Time element

2022-07-10T11:55:25Z

Pigsonthewing: /* noon and midnight */ c

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element 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|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,

[[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 ==
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 <code><input></code> elements allow and vice-versa. 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"> - <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)
</nowiki></pre>

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

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

<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-1600"[http://en.wikipedia.org/wiki/Basawan]), 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:Javarome|Jérôme Beau]] provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :<pre><nowiki><time datetime="1855-06-18" certainty="P3D">around 18 June 1855</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time></nowiki></pre>
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)
* 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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== 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.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-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 <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== 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 ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
***[Belated response, as I stopped following this site a long time ago (not least because of the snide and derogatory tone of some comments, of which the above is a fine example), and only revisited by chance]. Had I said "international readability is irrelevant", you might have a point. I did not, and you misquoted me. I actually said (emphasis added for clarity) "'international' readability is irrelevant, '''''when pages are otherwise in one language or another'''''". While YYYY-MM-DD format is relevant in a-lingual contexts such as code and data, ''when a page is in a specific language'' then the prose date ''in that language'' is the most accessible to its target audience (An example would be the use of "24 November 2011" on this page. In your own signature). Making the date accessible to readers of other languages - especially at the cost of reduced accessibility for the target audience - is irrelevant, if the reader cannot understand the surrounding text. Nor do I "assume Western bias". In this case, what I said was "accessible prose such as, say, '5 August 2010' or 'August 5th, 2010'". Note the inclusion of the phrase "such as, say", which indicates that the following examples are just that: ''examples''. I gave my examples in English, because discussion on this page is carried out in English. But what I said holds true if the date is written in Urdu, Mandarin, Arabic, Japanese, or any other specific language. I posit that 80% of the world do not use YYYY-MM-DD dates outside of special use cases such as those I mention; and still evidence to the contrary is lacking. Nor do I hold an "anti-internationalisation position" (assuming that is what you mean by the far from internationally accessible "i18n"). Once again, I must ask you not to attempt to speak for me. My objection stands. [[User:Pigsonthewing|Andy Mabbett]] 11:49, 10 July 2022 (UTC)
* +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)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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)
***Please do not rewrite or edit my comments. [[User:Pigsonthewing|Andy Mabbett]] 11:51, 10 July 2022 (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.
:The words "noon" and "midnight" may be specific to English (the language used on this page); the concepts are not. 00:00:00 is not "12am" and 12:00:00 is not "12pm". [[User:Pigsonthewing|Andy Mabbett]] 11:55, 10 July 2022 (UTC)

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

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

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio 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: [http://en.wikipedia.org/wiki/ISO_8601#Durations 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 ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><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></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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 ===
<div class="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. [[User:Tantek|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. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration 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. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
* '''fuzzy durations'''.
** [[User:Javarome|Jérôme Beau]] As per fuzzy dates mentioned above, durations should allow fuziness in durations :<pre><nowiki><time datetime="P1H" certainty="P5M">one hour, more or less five minutes</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="P1H" certainty="P1M,P30S">one hour, up to 1 minute shorter or 30 seconds longer</time></nowiki></pre>
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar 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 ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

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

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

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

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

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

[[Category:Proposals]]

Time element

2022-07-10T11:51:38Z

Pigsonthewing: /* am pm discussion */ c

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element 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|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,

[[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 ==
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 <code><input></code> elements allow and vice-versa. 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"> - <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)
</nowiki></pre>

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

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

<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-1600"[http://en.wikipedia.org/wiki/Basawan]), 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:Javarome|Jérôme Beau]] provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :<pre><nowiki><time datetime="1855-06-18" certainty="P3D">around 18 June 1855</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time></nowiki></pre>
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)
* 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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== 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.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-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 <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== 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 ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
***[Belated response, as I stopped following this site a long time ago (not least because of the snide and derogatory tone of some comments, of which the above is a fine example), and only revisited by chance]. Had I said "international readability is irrelevant", you might have a point. I did not, and you misquoted me. I actually said (emphasis added for clarity) "'international' readability is irrelevant, '''''when pages are otherwise in one language or another'''''". While YYYY-MM-DD format is relevant in a-lingual contexts such as code and data, ''when a page is in a specific language'' then the prose date ''in that language'' is the most accessible to its target audience (An example would be the use of "24 November 2011" on this page. In your own signature). Making the date accessible to readers of other languages - especially at the cost of reduced accessibility for the target audience - is irrelevant, if the reader cannot understand the surrounding text. Nor do I "assume Western bias". In this case, what I said was "accessible prose such as, say, '5 August 2010' or 'August 5th, 2010'". Note the inclusion of the phrase "such as, say", which indicates that the following examples are just that: ''examples''. I gave my examples in English, because discussion on this page is carried out in English. But what I said holds true if the date is written in Urdu, Mandarin, Arabic, Japanese, or any other specific language. I posit that 80% of the world do not use YYYY-MM-DD dates outside of special use cases such as those I mention; and still evidence to the contrary is lacking. Nor do I hold an "anti-internationalisation position" (assuming that is what you mean by the far from internationally accessible "i18n"). Once again, I must ask you not to attempt to speak for me. My objection stands. [[User:Pigsonthewing|Andy Mabbett]] 11:49, 10 July 2022 (UTC)
* +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)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

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

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio 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: [http://en.wikipedia.org/wiki/ISO_8601#Durations 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 ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><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></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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 ===
<div class="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. [[User:Tantek|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. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration 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. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
* '''fuzzy durations'''.
** [[User:Javarome|Jérôme Beau]] As per fuzzy dates mentioned above, durations should allow fuziness in durations :<pre><nowiki><time datetime="P1H" certainty="P5M">one hour, more or less five minutes</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="P1H" certainty="P1M,P30S">one hour, up to 1 minute shorter or 30 seconds longer</time></nowiki></pre>
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar 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 ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

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

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

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

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

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

[[Category:Proposals]]

Time element

2022-07-10T11:49:42Z

Pigsonthewing: /* nested time discussion */ r

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element 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|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,

[[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 ==
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 <code><input></code> elements allow and vice-versa. 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"> - <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)
</nowiki></pre>

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

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

<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-1600"[http://en.wikipedia.org/wiki/Basawan]), 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:Javarome|Jérôme Beau]] provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :<pre><nowiki><time datetime="1855-06-18" certainty="P3D">around 18 June 1855</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time></nowiki></pre>
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)
* 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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== 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.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-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 <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== 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 ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
***[Belated response, as I stopped following this site a long time ago (not least because of the snide and derogatory tone of some comments, of which the above is a fine example), and only revisited by chance]. Had I said "international readability is irrelevant", you might have a point. I did not, and you misquoted me. I actually said (emphasis added for clarity) "'international' readability is irrelevant, '''''when pages are otherwise in one language or another'''''". While YYYY-MM-DD format is relevant in a-lingual contexts such as code and data, ''when a page is in a specific language'' then the prose date ''in that language'' is the most accessible to its target audience (An example would be the use of "24 November 2011" on this page. In your own signature). Making the date accessible to readers of other languages - especially at the cost of reduced accessibility for the target audience - is irrelevant, if the reader cannot understand the surrounding text. Nor do I "assume Western bias". In this case, what I said was "accessible prose such as, say, '5 August 2010' or 'August 5th, 2010'". Note the inclusion of the phrase "such as, say", which indicates that the following examples are just that: ''examples''. I gave my examples in English, because discussion on this page is carried out in English. But what I said holds true if the date is written in Urdu, Mandarin, Arabic, Japanese, or any other specific language. I posit that 80% of the world do not use YYYY-MM-DD dates outside of special use cases such as those I mention; and still evidence to the contrary is lacking. Nor do I hold an "anti-internationalisation position" (assuming that is what you mean by the far from internationally accessible "i18n"). Once again, I must ask you not to attempt to speak for me. My objection stands. [[User:Pigsonthewing|Andy Mabbett]] 11:49, 10 July 2022 (UTC)
* +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)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

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

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio 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: [http://en.wikipedia.org/wiki/ISO_8601#Durations 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 ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><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></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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 ===
<div class="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. [[User:Tantek|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. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration 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. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
* '''fuzzy durations'''.
** [[User:Javarome|Jérôme Beau]] As per fuzzy dates mentioned above, durations should allow fuziness in durations :<pre><nowiki><time datetime="P1H" certainty="P5M">one hour, more or less five minutes</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="P1H" certainty="P1M,P30S">one hour, up to 1 minute shorter or 30 seconds longer</time></nowiki></pre>
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar 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 ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

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

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

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

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

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

[[Category:Proposals]]

Time element

2011-07-14T20:33:46Z

Pigsonthewing: /* duration discussion */ fix

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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*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 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)
** 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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* 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 month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

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

== year week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <code><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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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.

= 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 [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnY,nMo,nD,nH,nMin,nS
** where P, Y, Mo, D, H, Min, S are case-insensitive literals.
** n is a fixed point number expressible with a decimal point
** and the intervening commas ',' are required when more than one time duration unit is given.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3Min,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42Min,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><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></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="P96min">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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
*** "Mo" and "Min" standard abbreviations for Months and Minutes for disambiguation.

=== duration discussion ===
<div class="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 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])

* ...
</div>

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

[[Category:Proposals]]

Time element

2011-07-14T20:33:11Z

Pigsonthewing: /* duration examples */ ce

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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*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 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)
** 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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* 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 month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

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

== year week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <code><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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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.

= 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 [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnY,nMo,nD,nH,nMin,nS
** where P, Y, Mo, D, H, Min, S are case-insensitive literals.
** n is a fixed point number expressible with a decimal point
** and the intervening commas ',' are required when more than one time duration unit is given.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3Min,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42Min,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><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></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="P96min">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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
*** "Mo" and "Min" standard abbreviations for Months and Minutes for disambiguation.

=== duration discussion ===
<div class="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 20:23, 14 July 2011 (UTC) (as Wikipedia editor who deployed hAudio there)
* ...
</div>

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

[[Category:Proposals]]

Time element

2011-07-14T20:32:29Z

Pigsonthewing: /* duration examples */ +1

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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*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 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)
** 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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* 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 month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

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

== year week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <code><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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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.

= 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 [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnY,nMo,nD,nH,nMin,nS
** where P, Y, Mo, D, H, Min, S are case-insensitive literals.
** n is a fixed point number expressible with a decimal point
** and the intervening commas ',' are required when more than one time duration unit is given.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3Min,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42Min,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon])
Existing markup is:
<pre><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></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="P96min">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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
*** "Mo" and "Min" standard abbreviations for Months and Minutes for disambiguation.

=== duration discussion ===
<div class="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 20:23, 14 July 2011 (UTC) (as Wikipedia editor who deployed hAudio there)
* ...
</div>

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

[[Category:Proposals]]

Time element

2011-07-14T20:23:03Z

Pigsonthewing: /* duration discussion */ =1

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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*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 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)
** 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]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* 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 month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

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

== year week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <code><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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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.

= 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 [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnY,nMo,nD,nH,nMin,nS
** where P, Y, Mo, D, H, Min, S are case-insensitive literals.
** n is a fixed point number expressible with a decimal point
** and the intervening commas ',' are required when more than one time duration unit is given.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3Min,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>The movie is <time datetime="P96min">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations 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
*** "Mo" and "Min" standard abbreviations for Months and Minutes for disambiguation.

=== duration discussion ===
<div class="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 20:23, 14 July 2011 (UTC) (as Wikipedia editor who deployed hAudio there)
* ...
</div>

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

[[Category:Proposals]]

RelExtensions

2011-03-19T00:14:51Z

Pigsonthewing: Citation Typing Ontology (CiTO)

This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it. Note that rel tokens are ASCII-lowercase before comparison against canonical value, so the canonical values should be listed without uppercase ASCII letters.

{| class="wikitable sortable"
|-
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description
! Link to more details
! Synonyms
! Status
|-
| pronunciation
| external resource
| not allowed
| The referenced file contains a set of rules that associates strings of characters (e.g. words) with pronunciation instructions. For example, a rule can define whether the word "tomato" is to be spoken in the british or north-american way. These pronunciation rules should be processed by voice-enabled user-agents (e.g. web browsers that support TTS rendering), but conversely, "pronunciation" link/rel files can be completely ignored by systems that do not have speech capabilities. An example of possible format is W3C PLS (Pronunciation Lexicon Specification), with the MIME type "application/pls+xml" (and usually, the extension ".pls"). When several pronunciation lexicons are referenced within a single HTML document, and/or when a pronunciation rule is specified more than once for a given string of characters, the last occurrence of the rule takes precedence (in document order), such that any previously-defined pronunciation rule gets overridden.
| [http://www.w3.org/TR/pronunciation-lexicon/ Pronunciation Lexicon Specification (PLS) Version 1.0 (W3C Recommendation 14 October 2008)] <br/> [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7601 Previously-filed bug #7601]
|
| Proposal
|-
| accessibility
| hyperlink
| hyperlink
| The linked document contains accessibility information for the linking document.
| [http://www.brucelawson.co.uk/2009/rel-accessibility/ Bruce Lawson]
|
| Proposal
|-
| acquaintance
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| admin
| hyperlink
| hyperlink
| The linked document contains administrative option(s) for the current document and related pages.
|
| option
| Proposal
|-
| ajax
| not allowed
| hyperlink
| The link is controlled through javascript, and will load the page linked to though an ajax interface. Without javascript, it should behave as a normal "a" tag, and content change is done server side.
|
|
| Proposal
|-
| alternate
|colspan=6| See HTML5
|-
| answer
| hyperlink
| hyperlink
| A link to the answer to the question this section or document asks, e.g. in a FAQ or in a sample exam. Unlike ‘reply’ or ‘comment’ this resource necessarily solves the problem.
| [[Talk:RelExtensions#Q_and_A|Q&A]]
| (reply, comment)
| Proposal
|-
| application-manifest
| external resource
| Not allowed
| A manifest for this web application. The manifest contains metadata about the web application, such as its name, description, and permissions the application might require.
|
|
| Proposal
|-
| archives
|colspan=6| See HTML5
|-
| author
|colspan=6| See HTML5
|-
| bookmark
|colspan=6| See HTML5
|-
| canonical
| hyperlink
| not allowed
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter. Links with rel=canonical must not specify a language, type, or different kind of media; the referenced document must have the same language, type and target media.
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]
|
| Proposal
|-
| canonical-domain
| external resource
| not allowed
| More than one domain may have largely similar or identical content but only one of the domains should be indexed for search engines. E.g., a company may have short and long domain names for the same content.
For security against traffic theft, rev must be meaningless.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]
|
| Proposal
|-
| canonical-first
| external resource
| hyperlink
| Where the canonical value should point to a group of pages, but the link can point to only one page, the group of pages can be clarified by choosing the first page in the group and assigning the URL for this rel link.
For security against traffic theft, rev must be meaningless.<br />
This is only shorthand for providing two link elements, one on the noncanonical page to a "canonical" page and the other on the canonical page to the "first" page of the group.
Where the group of pages corresponds to a subdirectory and a canonical URL value can point to the subdirectory resulting in a user arriving at the subdirectory's index page which is part of the group, this shorthand is unnecessary and one rel="canonical" will suffice.
| [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]
|
| Proposal
|-
| canonical-human
| external resource
| hyperlink
| Pages about a person across many websites can be associated based on name, nationality, birthplace, dates of birth and death, when flourished, and other identifiers.
Search engines could more consistently aggregate same-person pages with less confusion due to name similarity.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681 W3C Bug 7681]
|
| Proposal
|-
| canonical-organization
| external resource
| hyperlink
| Pages about an organization across many websites can be associated based on name, headquarters site, and other identifiers.
Search engines could more consistently aggregate same-organization pages with less confusion due to name similarity.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7682 W3C Bug 7682]
|
| Proposal
|-
| canonical-wwwnone
| external resource
| hyperlink
| Both bare and www-prefixed domain names usually direct to the same site. Especially when external links to a site vary in the form used, search engine indexing concentrated on only one domain form may raise its credibility. The rel value is the form preferred for indexing, e.g., href="http://example.net". Nothing to the right of the top-level domain is needed.
For security against traffic theft, rev must be meaningless.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]
|
| Proposal
|-
| chapter
| hyperlink
| hyperlink
| Target document is a subdocument of the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
| section, subsection, appendix
| Proposal
|-
| child
| hyperlink
| hyperlink
| the referenced person is a child of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| co-resident
| hyperlink
| hyperlink
| the referenced person lives in the same residence as the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| co-worker
| hyperlink
| hyperlink
| the referenced person is a co-worker of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| colleague
| hyperlink
| hyperlink
| the referenced person is a colleague of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| contact
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| contributor
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).
|
|
| Proposal
|-
| crush
| hyperlink
| hyperlink
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| date
| hyperlink
| hyperlink
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| dns-prefetch
| external resource
| not allowed
| Force the DNS lookup of specific hostnames.
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla DNS Prefetching], <br />[http://dev.chromium.org/developers/design-documents/dns-prefetching Chromium DNS Prefetching]
|
| Proposal
|-
| edit
| hyperlink
| hyperlink
| Target document is an editable version of the current document.
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]
|
| Proposal
|-
| edituri
| hyperlink
| not allowed
| a link to an RSD file describing how to edit the given page.
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]
|
| Proposal
|-
| enclosure
| hyperlink
| hyperlink
| the destination of the hyperlink is intended to be downloaded and cached.
| [http://microformats.org/wiki/rel-enclosure rel-enclosure]
|
| Proposal
|-
| enlarged
| not allowed
| hyperlink
| For anchors that have one child image element, indicates that the linked document is an image file which is the same as the child image element of the link except a larger size (dimensions).
| [http://dvdgoss.wordpress.com/2010/04/26/the-case-for-relenlarge-in-html5/ David Goss]
|
| Proposal
|-
| external
|colspan=6| See HTML5
|-
| extension
| hyperlink
| hyperlink
| Browser extension
| [http://mozillalabs.com/jetpack/2010/05/12/indexing-and-auto-detecting-browser-extensions-on-the-web/ Mozilla Labs]
|
| Proposal
|-
| first
|colspan=6| See HTML5
|-
| friend
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| gallery
| hyperlink
| hyperlink
| A ''graphic'' index that the current document or section is a part of or that illustrates the same topic.
|
| (index, list)
| Proposal
|-
| glossary
| hyperlink
| hyperlink
| Target document provides definitions for words in current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| Proposal
|-
| help
|colspan=6| See HTML5
|-
| hub
| hyperlink
| not allowed
| Indicates a URL which implements both sides of the PubSubHubbub protocol.
| [http://code.google.com/p/pubsubhubbub/ PubSubHubbub]
|
| Proposal
|-
| i18nrules
| hyperlink
| not allowed
| Target document provides ITS (Internationalization tag Set) rules for processing the current document.
| [http://www.w3.org/TR/its/ ITS]
|
| Proposal
|-
| icon
|colspan=6| See HTML5
|-
| index
|colspan=6| See HTML5
|-
| jump
| not allowed
| hyperlink
| Indicates a same page jump from the current fragment to another fragment. (E.g. sometimes online newspapers insert direct text saying "article continues below the image/advert" - they could instead use "jump" link. Ultimately, it indicates a page internal link.)
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]
|
| Proposal
|-
| kin
| hyperlink
| hyperlink
| the referenced person is part of the extended family of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| lang-alt-[ISO 639-1 code]
| hyperlink
| hyperlink
| The linked document contains a version of the current document in an alternative language. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.
|
|
| Proposal
|-
| lang-orig-[ISO 639-1 code]
| hyperlink
| hyperlink
| The linked document contains a version of the current document in the language the document was originally written in. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.
|
|
| Proposal
|-
| last
|colspan=6| See HTML5
|-
| latest-version
| hyperlink
| hyperlink
| The referenced document is the latest version of the current document.
| [http://www.iana.org/assignments/link-relations/link-relations.txt], [http://tools.ietf.org/search/rfc5829#section-3.2 RFC5829]
|
| Proposal
|-
| license
|colspan=6| See HTML5
|-
| login
| hyperlink
| hyperlink
| The login keyword indicates that the referenced document provides an interface (user, pwd) to authenticate a registered user of the page/or to registrate a new user.
|
| search
| Proposal
|-
| logout
| external resource
| not allowed
| The linked document provides a resource for the UA to request when all currently open documents of the same "group" are closed (to facilitate logging out the current user).
| [[LogoutRelExtension]]
|
| Proposal
|-
| <span id="longdesc">longdesc</span>
| hyperlink
| hyperlink
| Related to [http://www.w3.org/html/wg/tracker/issues/30 ISSUE-30]. <br/><abbr title="Assistive Technology">AT</abbr> should treat an element wrapped in a link with <code>rel="longdesc"</code> as equivalent to an element with <code>longdesc="URI"</code>.
| (1) [http://lists.w3.org/Archives/Public/public-html/2007Jun/0738.html Eric Eggert's original proposal, 25th of June 2007], <br/>(2) [http://lists.w3.org/Archives/Public/public-html/2007Jun/0798.html Maciej's comment, 25th of June 2007], <br/>(3) [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10434 Bug 10434, the HTMLwg, 2010]<br/>(4) [http://microformats.org/wiki/existing-rel-values#POSH_usage rel="longdesc" listed as POSH in Microformats.org]
| <code><foo longdesc="URL"/></code> <br/>is synonymous to <br/><code><a rel="longdesc" href="URL"><foo/></a></code>
| Proposal
|-
| map
| hyperlink
| hyperlink
| the referenced document represents a map of the location of the subject of the current document; parsers ''may'' use the URI or target page to determine coordinates.
| to follow
|
| Proposal
|-
| me
| hyperlink
| hyperlink
| the referenced document represents the same person as does the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| met
| hyperlink
| hyperlink
| this person has met the referenced person
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| meta
| external resource
| hyperlink
| publishing RDF/FOAF files
| [http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#transport RDF], [http://xmlns.com/foaf/spec/#sec-autodesc FOAF]
|
| Proposal
|-
| muse
| hyperlink
| hyperlink
| the referenced person inspires the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| neighbor
| hyperlink
| hyperlink
| the referenced person lives nearby the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| next
|colspan=6| See HTML5
|-
| next-archive
| hyperlink
| hyperlink
| A URI that refers to the immediately following archive document.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]
|
| Proposal
|-
| nofollow
|colspan=6| See HTML5
|-
| noreferrer
|colspan=6| See HTML5
|-
| noprefetch
| external resource
| hyperlink
| Denies prefetching (not fetching) as a cost-control option for website owners, especially where pages are dynamic, leading to prefetching of wrong and useless pages.<br />
The link provides a per-page denial whereas a and area provide a per-element denial.<br />
For link, attributes rel="noprefetch" denies prefetching of the page at the href URL and rev="noprefetch" denies prefetching of the page bearing the link.<br />
For a and area, rel is as above and rev is meaningless.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 W3C Bug 7918]
|
| Proposal
|-
| note
| not allowed
| hyperlink
| An in-page or out-page jump to a footnote. This encompasses ''note'', ''footnote'', ''endnote'', and ''sidenote''.
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]
|
| Proposal
|-
| openid.delegate
| external resource
| not allowed
| OpenID 1.1 authentication delegation
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]
|
| Proposal
|-
| openid.server
| external resource
| not allowed
| OpenID 1.1 authentication delegation
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]
|
| Proposal
|-
| openid2.local_id
| external resource
| not allowed
| OpenID 2.0 authentication delegation
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]
|
| Proposal
|-
| openid2.provider
| external resource
| not allowed
| OpenID 2.0 authentication endpoint
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]
|
| Proposal
|-
| parent
| hyperlink
| hyperlink
| the referenced person is a parent of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| payment
| hyperlink
| hyperlink
| A URI where payment is accepted.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations]
|
| Proposal
|-
| pgpkey
| hyperlink
| not allowed
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]
|
| Proposal
|-
| pingback
|colspan=6| See HTML5
|-
| prefetch
|colspan=6| See HTML5
|-
| presentation
| external resource
| hyperlink
| Like ‘print’ this relation references a resource that represents the same content or topic, but in a ''very'' different manner. It is similar to media=projection, but is to be used where text is substituted by graphics, animations and sounds, which goes beyond mere style switching.
This relation is also appropriate for links from thumbnail to full resolution images.
|
| slides, slideshow
| Proposal
|-
| prev
|colspan=6| See HTML5
|-
| prev-archive
| hyperlink
| hyperlink
| A URI that refers to the immediately preceding archive document.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]
|
| Proposal
|-
| print
| external resource
| hyperlink
| The referenced document is recommended for printing, even though the referent document is capable of being printed and both documents are of the same type, medium, and language. A typical case is where content spread over multiple pages is also available on a single page that is more convenient to print.
This is semantically more specific than "canonical" and "alternate". Where type, medium, and/or language differ, consider "alternate"; where any of them differ but the purpose is printing, consider applying both values.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7645 W3C Bug 7645]
|
| Proposal
|-
| profile
| hyperlink
| hyperlink
| this referenced link is a metadata profile for the current document
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles], <br />[http://www.w3.org/2003/g/glean-profile Example of profile in a-elements]
|
| Proposal
|-
| question
| hyperlink
| hyperlink
| A link to the question this section or document answers, e.g. in a FAQ or in a sample exam.
| [[Talk:RelExtensions#Q_and_A|Q&A]]
| topic, subject, problem, (up)
| Proposal
|-
| related
| hyperlink
| hyperlink
| this referenced link identifies a resource related to the current document
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]
|
| Proposal
|-
| reply
| hyperlink
| hyperlink
| A follow-up posting to this document or section or in the thread this document or section is an index of.
| [[Talk:RelExtensions#Threading|Thread]]
| posting, comment
| Proposal
|-
| resource-package
| external resource
| not allowed
| The linked document is a zipped resource package
| [http://limi.net/articles/resource-packages/ Resource Packages]
|
| Proposal
|-
| resources
| external resource
| not allowed
| a higher level alternative to HTTP Content Negotiation for other resources linked from the document, in a yet to be specified format
|
| resource-description, content-negotiation
| Proposal
|-
| reviewer
| hyperlink
| not allowed
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.
| [http://wiki.csswg.org/test/css2.1/format#reviewer]
|
| Proposal
|-
| script
| not allowed
| not allowed
| Was proposed to replace <script>. Use <script> instead.
| none
|
| Rejected
|-
| search
|colspan=6| See HTML5
|-
| self
| hyperlink
| hyperlink
| A URI that refers to a resource equivalent to the containing element.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc4287 RFC4287]
|
| Proposal
|-
| service
| external resource
| not allowed
| Points to a resource describing a service API
| [[ServiceRelExtension]]
|
| Proposal
|-
| shortlink
| hyperlink
| hyperlink
| Identifies a shorter form of the URL for the current document, provided by the document owner.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]
|
| Proposal
|-
| sibling
| hyperlink
| hyperlink
| the referenced person is a sibling of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| sidebar
|colspan=6| See HTML5
|-
| spouse
| hyperlink
| hyperlink
| the referenced person is a spouse of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| statechart
| external resource
| not allowed
| A reference to an SCXML document that controls the application-flow of the current HTML document
| [http://www.w3.org/TR/scxml/ SCXML]
|
| Proposal
|-
| stylesheet
|colspan=6| See HTML5
|-
| subresource
| hyperlink
| not allowed
| The referenced document is a subresource of the current document.
|
|
| Proposal
|-
| sweetheart
| hyperlink
| hyperlink
| this person considers the referenced person to be their sweetheart
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| tag
|colspan=6| See HTML5
|-
| technicalauthor
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.
|
|
| Proposal
|-
| thread
| hyperlink
| hyperlink
| A hierarchic list of topic(s) and replies where this document or section belongs to either one.
| [[Talk:RelExtensions#Threading|Thread]]
| (index)
| Proposal
|-
| timesheet
| external resource
| not allowed
| SMIL Timesheet
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]
|
| Proposal
|-
| topic
| hyperlink
| hyperlink
| The initial posting this document or section is a reply to or index of.
| [[Talk:RelExtensions#Threading|Thread]]
| subject, (top)
| Proposal
|-
| translatedfrom
| hyperlink
| hyperlink
| The linked document is the page/email that has been translation source for the current document. It also indicates that the current document is a translation and not an original work.
|
|
| Proposal
|-
| translator
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page. It also indicates that the current page is a translation of an other document, which should be linked through a rel="translatedfrom".
|
|
| Proposal
|-
| up
|colspan=6| See HTML5
|-
| us
| hyperlink
| hyperlink
| The referenced document represents the same organisation as does the current document [cf rel-me]
|
|
| Proposal
|-
| webmaster
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) available for requests about the content of the page.
|
| maintainer
| Proposal
|-
| widget
| hyperlink
| hyperlink
| Points to a widget.
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]
|
| Proposal
|-
| wlwmanifest
| hyperlink
| not allowed
| A link to a manifest for Windows Live Writer.
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]
|
| Proposal
|}


The "Effect on link" column must either say "not allowed" if the rel value is not allowed on <link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.

The "Effect on a and area" column must either say "not allowed" or "hyperlink".

For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".

For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification].

===See also===
*[http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].
*[http://blogs.plos.org/mfenner/2011/02/14/how-to-use-citation-typing-ontology-cito-in-your-blog-posts/ How to use Citation Typing Ontology (CiTO) in your blog posts] - proposes several values for marking up academic citations, but confuses the direction of the relationship (note comments)

[[Category:Registries]]

Time element

2010-08-26T23:10:58Z

Pigsonthewing: /* Calendar scale use cases */ time travel ;-)

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.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* 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.

Time element

2010-08-23T11:24:42Z

Pigsonthewing: /* Fuzzy dates */ R

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.

Time element

2010-08-22T22:40:26Z

Pigsonthewing: /* Calendar scale discussion */ r

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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.

Time element

2010-08-22T22:35:58Z

Pigsonthewing: /* Fuzzy dates */ c

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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* …
</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.

Time element

2010-08-22T22:34:49Z

Pigsonthewing: /* Fuzzy dates */ ~~~~

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 eras ("Edwardian", "bronze age", "Jurassic")".

;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 i) any definitions emerging from the EDTF efforts and/or 2) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. its 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)
* ...
</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.
* …
</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.

Time element

2010-08-22T22:34:19Z

Pigsonthewing: /* Fuzzy dates */ r

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 eras ("Edwardian", "bronze age", "Jurassic")".

;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 i) any definitions emerging from the EDTF efforts and/or 2) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. its not that "this isn't well thought through" so much as "this is brought here for the community to think through".
* ...
</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.
* …
</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.

RelExtensions

2010-08-21T19:58:19Z

Pigsonthewing: map

This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it. Note that rel tokens are ASCII-lowercase before comparison against canonical value, so the canonical values should be listed without uppercase ASCII letters.

{| class=wikitable
|-
! rowspan=2 | Keyword
! colspan=2 | Effect on...
! rowspan=2 | Brief description
! rowspan=2 | Link to more details
! rowspan=2 | Synonyms
! rowspan=2 | Status
|-
! link
! a and area
|-
| accessibility
| hyperlink
| hyperlink
| The linked document contains accessibility information for the linking document.
| [http://www.brucelawson.co.uk/2009/rel-accessibility/ Bruce Lawson]
|
| Proposal
|-
| acquaintance
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| ajax
| not allowed
| hyperlink
| The link is controlled through javascript, and will load the page linked to though an ajax interface. Without javascript, it should behave as a normal "a" tag, and content change is done server side.
|
|
| Proposal
|-
| alternate
|colspan=6| See HTML5
|-
| archives
|colspan=6| See HTML5
|-
| author
|colspan=6| See HTML5
|-
| bookmark
|colspan=6| See HTML5
|-
| canonical
| hyperlink
| not allowed
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter.
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]
|
| Proposal
|-
| canonical-domain
| external resource
| not allowed
| More than one domain may have largely similar or identical content but only one of the domains should be indexed for search engines. E.g., a company may have short and long domain names for the same content.
For security against traffic theft, rev must be meaningless.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]
|
| Proposal
|-
| canonical-first
| external resource
| hyperlink
| Where the canonical value should point to a group of pages, but the link can point to only one page, the group of pages can be clarified by choosing the first page in the group and assigning the URL for this rel link.
For security against traffic theft, rev must be meaningless.<br />
This is only shorthand for providing two link elements, one on the noncanonical page to a "canonical" page and the other on the canonical page to the "first" page of the group.
Where the group of pages corresponds to a subdirectory and a canonical URL value can point to the subdirectory resulting in a user arriving at the subdirectory's index page which is part of the group, this shorthand is unnecessary and one rel="canonical" will suffice.
| [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]
|
| Proposal
|-
| canonical-human
| external resource
| hyperlink
| Pages about a person across many websites can be associated based on name, nationality, birthplace, dates of birth and death, when flourished, and other identifiers.
Search engines could more consistently aggregate same-person pages with less confusion due to name similarity.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681 W3C Bug 7681]
|
| Proposal
|-
| canonical-organization
| external resource
| hyperlink
| Pages about an organization across many websites can be associated based on name, headquarters site, and other identifiers.
Search engines could more consistently aggregate same-organization pages with less confusion due to name similarity.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7682 W3C Bug 7682]
|
| Proposal
|-
| canonical-wwwnone
| external resource
| hyperlink
| Both bare and www-prefixed domain names usually direct to the same site. Especially when external links to a site vary in the form used, search engine indexing concentrated on only one domain form may raise its credibility. The rel value is the form preferred for indexing, e.g., rel="http://example.net". Nothing to the right of the top-level domain is needed.
For security against traffic theft, rev must be meaningless.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]
|
| Proposal
|-
| chapter
| hyperlink
| hyperlink
| Target document is a subdocument of the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
| section, subsection, appendix
| Proposal
|-
| child
| hyperlink
| hyperlink
| the referenced person is a child of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| co-resident
| hyperlink
| hyperlink
| the referenced person lives in the same residence as the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| co-worker
| hyperlink
| hyperlink
| the referenced person is a co-worker of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| colleague
| hyperlink
| hyperlink
| the referenced person is a colleague of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| contact
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| contributor
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).
|
|
| Proposal
|-
| crush
| hyperlink
| hyperlink
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| date
| hyperlink
| hyperlink
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| details
| hyperlink
| hyperlink
| The referenced document contains additional (or complete) details about the current document (for example, a "read more..." hyperlink on a blog page that leads to the full posting).
|
|
| Proposal
|-
| dns-prefetch
| external resource
| not allowed
| Force the DNS lookup of specific hostnames.
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla DNS Prefetching], <br />[http://dev.chromium.org/developers/design-documents/dns-prefetching Chromium DNS Prefetching]
|
| Proposal
|-
| edit
| hyperlink
| hyperlink
| Target document is an editable version of the current document.
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]
|
| Proposal
|-
| edituri
| hyperlink
| not allowed
| a link to an RSD file describing how to edit the given page.
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]
|
| Proposal
|-
| enclosure
| hyperlink
| hyperlink
| the destination of the hyperlink is intended to be downloaded and cached.
| [http://microformats.org/wiki/rel-enclosure rel-enclosure]
|
| Proposal
|-
| enlarged
| not allowed
| hyperlink
| For anchors that have one child image element, indicates that the linked document is an image file which is the same as the child image element of the link except a larger size (dimensions).
| [http://dvdgoss.wordpress.com/2010/04/26/the-case-for-relenlarge-in-html5/ David Goss]
|
| Proposal
|-
| external
|colspan=6| See HTML5
|-
| extension
| hyperlink
| hyperlink
| Browser extension
| [http://mozillalabs.com/jetpack/2010/05/12/indexing-and-auto-detecting-browser-extensions-on-the-web/ Mozilla Labs]
|
| Proposal
|-
| first
|colspan=6| See HTML5
|-
| friend
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| glossary
| hyperlink
| hyperlink
| Target document provides definitions for words in current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| Proposal
|-
| help
|colspan=6| See HTML5
|-
| hub
| hyperlink
| not allowed
| Indicates a URL which implements both sides of the PubSubHubbub protocol.
| [http://code.google.com/p/pubsubhubbub/ PubSubHubbub]
|
| Proposal
|-
| i18nrules
| hyperlink
| not allowed
| Target document provides ITS (Internationalization tag Set) rules for processing the current document.
| [http://www.w3.org/TR/its/ ITS]
|
| Proposal
|-
| icon
|colspan=6| See HTML5
|-
| index
|colspan=6| See HTML5
|-
| jump
| not allowed
| hyperlink
| Indicates a same page jump from the current fragment to another fragment. (E.g. sometimes online newspapers insert direct text saying "article continues below the image/advert" - they could instead use "jump" link. Ultimately, it indicates a page internal link.)
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]
|
| Proposal
|-
| kin
| hyperlink
| hyperlink
| the referenced person is part of the extended family of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| lang-alt-[ISO 639-1 code]
| hyperlink
| hyperlink
| The linked document contains a version of the current document in an alternative language. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.
|
|
| Proposal
|-
| lang-orig-[ISO 639-1 code]
| hyperlink
| hyperlink
| The linked document contains a version of the current document in the language the document was originally written in. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.
|
|
| Proposal
|-
| last
|colspan=6| See HTML5
|-
| latest-version
| hyperlink
| hyperlink
| The referenced document is the latest version of the current document.
| [http://www.iana.org/assignments/link-relations/link-relations.txt], [http://tools.ietf.org/search/rfc5829#section-3.2 RFC5829]
|
| Proposal
|-
| license
|colspan=6| See HTML5
|-
| logout
| external resource
| not allowed
| The linked document provides a resource for the UA to request when all currently open documents of the same "group" are closed (to facilitate logging out the current user).
| [[LogoutRelExtension]]
|
| Proposal
|-
| map
| hyperlink
| hyperlink
| the referenced document represents a map of the location of the subject of the current document; parsers ''may'' use the URI or target page to determine coordinates.
| to follow
|
| Proposal
|-
| me
| hyperlink
| hyperlink
| the referenced document represents the same person as does the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| met
| hyperlink
| hyperlink
| this person has met the referenced person
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| muse
| hyperlink
| hyperlink
| the referenced person inspires the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| neighbor
| hyperlink
| hyperlink
| the referenced person lives nearby the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| next
|colspan=6| See HTML5
|-
| next-archive
| hyperlink
| hyperlink
| A URI that refers to the immediately following archive document.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]
|
| Proposal
|-
| nofollow
|colspan=6| See HTML5
|-
| noreferrer
|colspan=6| See HTML5
|-
| noprefetch
| external resource
| hyperlink
| Denies prefetching (not fetching) as a cost-control option for website owners, especially where pages are dynamic, leading to prefetching of wrong and useless pages.<br />
The link provides a per-page denial whereas a and area provide a per-element denial.<br />
For link, attributes rel="noprefetch" denies prefetching of the page at the href URL and rev="noprefetch" denies prefetching of the page bearing the link.<br />
For a and area, rel is as above and rev is meaningless.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 W3C Bug 7918]
|
| Proposal
|-
| note
| not allowed
| hyperlink
| An in-page or out-page jump to a footnote. This encompasses ''note'', ''footnote'', ''endnote'', and ''sidenote''.
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]
|
| Proposal
|-
| openid.delegate
| external resource
| not allowed
| OpenID 1.1 authentication delegation
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]
|
| Proposal
|-
| openid.server
| external resource
| not allowed
| OpenID 1.1 authentication delegation
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]
|
| Proposal
|-
| openid2.local_id
| external resource
| not allowed
| OpenID 2.0 authentication delegation
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]
|
| Proposal
|-
| openid2.provider
| external resource
| not allowed
| OpenID 2.0 authentication endpoint
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]
|
| Proposal
|-
| parent
| hyperlink
| hyperlink
| the referenced person is a parent of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| payment
| hyperlink
| hyperlink
| A URI where payment is accepted.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations]
|
| Proposal
|-
| pgpkey
| hyperlink
| not allowed
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]
|
| Proposal
|-
| pingback
|colspan=6| See HTML5
|-
| prefetch
|colspan=6| See HTML5
|-
| prev
|colspan=6| See HTML5
|-
| prev-archive
| hyperlink
| hyperlink
| A URI that refers to the immediately preceding archive document.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]
|
| Proposal
|-
| print
| external resource
| hyperlink
| The referenced document is recommended for printing, even though the referent document is capable of being printed and both documents are of the same type, medium, and language. A typical case is where content spread over multiple pages is also available on a single page that is more convenient to print.
This is semantically more specific than "canonical" and "alternate". Where type, medium, and/or language differ, consider "alternate"; where any of them differ but the purpose is printing, consider applying both values.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7645 W3C Bug 7645]
|
| Proposal
|-
| profile
| hyperlink
| hyperlink
| this referenced link is a metadata profile for the current document
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles], <br />[http://www.w3.org/2003/g/glean-profile Example of profile in a-elements]
|
| Proposal
|-
| related
| hyperlink
| hyperlink
| this referenced link identifies a resource related to the current document
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]
|
| Proposal
|-
| resource-package
| external resource
| not allowed
| The linked document is a zipped resource package
| [http://limi.net/articles/resource-packages/ Resource Packages]
|
| Proposal
|-
| reviewer
| hyperlink
| not allowed
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.
| [http://wiki.csswg.org/test/css2.1/format#reviewer]
|
| Proposal
|-
| script
| not allowed
| not allowed
| Was proposed to replace <script>. Use <script> instead.
| none
|
| Rejected
|-
| search
|colspan=6| See HTML5
|-
| self
| hyperlink
| hyperlink
| A URI that refers to a resource equivalent to the containing element.
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc4287 RFC4287]
|
| Proposal
|-
| service
| external resource
| not allowed
| Points to a resource describing a service API
| [[ServiceRelExtension]]
|
| Proposal
|-
| shortlink
| hyperlink
| hyperlink
| Identifies a shorter form of the URL for the current document, provided by the document owner.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]
|
| Proposal
|-
| sibling
| hyperlink
| hyperlink
| the referenced person is a sibling of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| sidebar
|colspan=6| See HTML5
|-
| spouse
| hyperlink
| hyperlink
| the referenced person is a spouse of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| statechart
| external resource
| not allowed
| A reference to an SCXML document that controls the application-flow of the current HTML document
| [http://www.w3.org/TR/scxml/ SCXML]
|
| Proposal
|-
| stylesheet
|colspan=6| See HTML5
|-
| sweetheart
| hyperlink
| hyperlink
| this person considers the referenced person to be their sweetheart
| [http://gmpg.org/xfn/11 XFN]
|
| Accepted
|-
| tag
|colspan=6| See HTML5
|-
| technicalauthor
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.
|
|
| Proposal
|-
| timesheet
| external resource
| not allowed
| SMIL Timesheet
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]
|
| Proposal
|-
| translatedfrom
| hyperlink
| hyperlink
| The linked document is the page/email that has been translation source for the current document. It also indicates that the current document is a translation and not an original work.
|
|
| Proposal
|-
| translator
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page. It also indicates that the current page is a translation of an other document, which should be linked through a rel="translatedfrom".
|
|
| Proposal
|-
| up
|colspan=6| See HTML5
|-
| us
| hyperlink
| hyperlink
| The referenced document represents the same organisation as does the current document [cf rel-me]
|
|
| Proposal
|-
| webmaster
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) available for requests about the content of the page.
|
| maintainer
| Proposal
|-
| widget
| hyperlink
| hyperlink
| Points to a widget.
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]
|
| Proposal
|-
| wlwmanifest
| hyperlink
| not allowed
| A link to a manifest for Windows Live Writer.
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]
|
| Proposal
|}

The "Effect on... link" column must either say "not allowed" if the rel value is not allowed on <link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.

The "Effect on... a and area" column must either say "not allowed" or "hyperlink".

For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".

For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification]. See also [http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].

Time element

2010-08-17T10:12:53Z

Pigsonthewing: /* Resources */ datetime-comments@w3.org. - anyone have archives?

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"

=== 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.
* ...
</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)

=== 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.
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* …
</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 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 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.

Time element

2010-08-17T10:11:05Z

Pigsonthewing: /* year only use cases */ commerce; sport; awards

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"

=== 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.
* ...
</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)

=== 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.
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* …
</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 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 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]
* [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.

Time element

2010-08-17T09:56:29Z

Pigsonthewing: /* Resources */ W3C Date and Time Formats discussion note

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

=== 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.
* ...
</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)

=== 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.
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* …
</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 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 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]
* [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.

Time element

2010-08-17T09:54:54Z

Pigsonthewing: /* Fuzzy dates */ reply to Lars Gunther

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

=== 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.
* ...
</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)

=== 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.
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* …
</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 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 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://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.

Time element

2010-08-15T10:16:43Z

Pigsonthewing: /* year only use cases */ Citations

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

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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.

Time element

2010-08-15T10:06:51Z

Pigsonthewing: /* year only use cases */ ce

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]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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.

Time element

2010-08-15T10:05:16Z

Pigsonthewing: o

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 ranks' ''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]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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.

Time element

2010-08-15T10:04:45Z

Pigsonthewing: /* year only use cases */ ce

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 ranks' ''authority'' (the person who named it, and the year they did so) always includes a while-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]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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.

Time element

2010-08-15T10:03:56Z

Pigsonthewing: /* year only use cases */ biological taxonomy

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 otehr ranks' ''authority'' (the peraon who anmed it, and tehayr they dis so) always includes a while-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]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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.

Time element

2010-08-12T12:49:51Z

Pigsonthewing: /* Resources */ fmt

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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.

Time element

2010-08-12T12:49:04Z

Pigsonthewing: /* Resources */ ce

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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 and <code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
* [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.

Time element

2010-08-12T12:19:06Z

Pigsonthewing: /* Resources */ + discussion

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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: <code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal and <code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
* [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.

Time element

2010-08-12T12:15:29Z

Pigsonthewing: /* Resources */ Time Ontology in OWL

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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: <code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal and <code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]

Time element

2010-08-12T10:30:18Z

Pigsonthewing: /* 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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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: <code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal and <code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]

Time element

2010-08-12T10:27:04Z

Pigsonthewing: /* Resources */ dcterms:temporal (will add commentary and move to better location later)

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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).
* ...
</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.
* …
</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 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 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 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://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: term <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]

Class

2010-08-11T21:02:31Z

Pigsonthewing: /* Current wording */ URL

Misapprehensions (citations to follow) abound about the purpose of the class attribute, which is often referred to, plural, as "CSS classes".

The wording in the spec should be changed to more clearly indicate the semantic nature of the class attribute, when used properly, and indicate the validity of its use in this way.

== Current wording ==

From: http://www.w3.org/TR/html5/elements.html#classes

<blockquote cite="http://www.w3.org/TR/html5/elements.html#classes">
<p>Every HTML element may have a class attribute specified.</p>

<p>The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.</p>

<p>The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)</p>

<p>Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.</p>

<p>There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.</p>
</blockquote>

== Suggested wording==

Please add and sign suggestions, so that a composite may be produced at later date. Emboldening may be used to identify changes, and will not be conveyed to the final version.

*replace the final paragraph with...
**There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the '''semantic''' nature of the content, rather than values that describe the desired presentation of the content. [[User:Pigsonthewing|Pigsonthewing]] 16:00, 11 August 2010 (UTC)

==Prior discussion ==
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.

== Bug ==
* [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10346 W3C bug 10346]

Time element

2010-08-11T16:41:35Z

Pigsonthewing: /* Syntax improvements for reducing DRY violations */ embolden

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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>
</div>
* +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).

== 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.
* …
</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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Time element

2010-08-11T16:40:35Z

Pigsonthewing: /* year only use cases */ typo

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/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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>
</div>
* +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).

== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Time element

2010-08-11T16:38:56Z

Pigsonthewing: /* Calendar scale use cases */ pre-Gregorian eras

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-ony; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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>
</div>
* +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).

== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Time element

2010-08-11T16:37:13Z

Pigsonthewing: /* Fuzzy dates */ Archaeological Periods list

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-ony; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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>
</div>
* +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).

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

=== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Time element

2010-08-11T16:32:38Z

Pigsonthewing: /* Fuzzy dates */ Time periods in astronomy

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-ony; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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 mailing list post] and prior discussion
;3 ...

<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>
</div>
* +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).

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

=== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Time element

2010-08-11T16:17:18Z

Pigsonthewing: /* year month related posts */ +1

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-ony; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</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 eras ("Edwardian", "bronze age", "Jurassic")".

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

<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>
</div>
* +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).

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

=== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Time element

2010-08-11T16:16:56Z

Pigsonthewing: /* year only related posts */ +1

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-ony; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]

=== 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...").
* ...
</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)

=== 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...").
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [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 eras ("Edwardian", "bronze age", "Jurassic")".

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

<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>
</div>
* +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).

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

=== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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 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 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>
* ...
</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://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)]

Class

2010-08-11T16:05:09Z

Pigsonthewing: /* Prior discussion */ from uFs wiki

Misapprehensions (citations to follow) abound about the purpose of the class attribute, which is often referred to, plural, as "CSS classes".

The wording in the spec should be changed to more clearly indicate the semantic nature of the class attribute, when used properly, and indicate the validity of its use in this way.

== Current wording ==
<blockquote>
<p>Every HTML element may have a class attribute specified.</p>

<p>The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.</p>

<p>The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)</p>

<p>Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.</p>

<p>There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.</p>
</blockquote>

== Suggested wording==

Please add and sign suggestions, so that a composite may be produced at later date. Emboldening may be used to identify changes, and will not be conveyed to the final version.

*replace the final paragraph with...
**There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the '''semantic''' nature of the content, rather than values that describe the desired presentation of the content. [[User:Pigsonthewing|Pigsonthewing]] 16:00, 11 August 2010 (UTC)

==Prior discussion ==
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.

== Bug ==
* [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10346 W3C bug 10346]

Class

2010-08-11T16:01:17Z

Pigsonthewing: /* Suggested wording */ '''

Misapprehensions (citations to follow) abound about the purpose of the class attribute, which is often referred to, plural, as "CSS classes".

The wording in the spec should be changed to more clearly indicate the semantic nature of the class attribute, when used properly, and indicate the validity of its use in this way.

== Current wording ==
<blockquote>
<p>Every HTML element may have a class attribute specified.</p>

<p>The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.</p>

<p>The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)</p>

<p>Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.</p>

<p>There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.</p>
</blockquote>

== Suggested wording==

Please add and sign suggestions, so that a composite may be produced at later date. Emboldening may be used to identify changes, and will not be conveyed to the final version.

*replace the final paragraph with...
**There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the '''semantic''' nature of the content, rather than values that describe the desired presentation of the content. [[User:Pigsonthewing|Pigsonthewing]] 16:00, 11 August 2010 (UTC)

==Prior discussion ==
* http://microformats.org/2005/10/19/more-than-styling

== Bug ==
* [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10346 W3C bug 10346]

Class

2010-08-11T16:00:19Z

Pigsonthewing: ce

Misapprehensions (citations to follow) abound about the purpose of the class attribute, which is often referred to, plural, as "CSS classes".

The wording in the spec should be changed to more clearly indicate the semantic nature of the class attribute, when used properly, and indicate the validity of its use in this way.

== Current wording ==
<blockquote>
<p>Every HTML element may have a class attribute specified.</p>

<p>The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.</p>

<p>The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)</p>

<p>Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.</p>

<p>There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.</p>
</blockquote>

== Suggested wording==

Please add and sign suggestions, so that a composite may be produced at later date

*replace the final paragraph with...
**There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the semantic nature of the content, rather than values that describe the desired presentation of the content. [[User:Pigsonthewing|Pigsonthewing]] 16:00, 11 August 2010 (UTC)

==Prior discussion ==
* http://microformats.org/2005/10/19/more-than-styling

== Bug ==
* [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10346 W3C bug 10346]

Class

2010-08-11T15:56:58Z

Pigsonthewing: /* Suggested wording */ +

There are many misapprehensions (citations to follow) abound about the purpose of the class attribute, which is often referred to, plural, as "CSS classes".

The wording in the spec should be changed to more clearly indicate the semantic nature of the class attribute, when used properly, and indicate the validuty of its use in this way.

== Current wording ==
<blockquote>
<p>Every HTML element may have a class attribute specified.</p>

<p>The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.</p>

<p>The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)</p>

<p>Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.</p>

<p>There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.</p>
</blockquote>

== Suggested wording==

Please add and sign suggestions, so that a composite may be produced at later date

*replace the final paragraph with...
** ...may be used for labelling, styling or indicating meaning" [[User:Pigsonthewing|Pigsonthewing]] 15:49, 11 August 2010 (UTC)
** ...may be used for labelling, styling or indicating semantics" [[User:Pigsonthewing|Pigsonthewing]] 15:51, 11 August 2010 (UTC)
** ...although classes allow content to be styled, they should be named to convey semantic meaning" [[User:Pigsonthewing|Pigsonthewing]] 15:52, 11 August 2010 (UTC)

==Prior discussion ==
* http://microformats.org/2005/10/19/more-than-styling

== Bug ==
* [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10346 W3C bug 10346]

Class

2010-08-11T15:56:25Z

Pigsonthewing: /* Current wording */ +

There are many misapprehensions (citations to follow) abound about the purpose of the class attribute, which is often referred to, plural, as "CSS classes".

The wording in the spec should be changed to more clearly indicate the semantic nature of the class attribute, when used properly, and indicate the validuty of its use in this way.

== Current wording ==
<blockquote>
<p>Every HTML element may have a class attribute specified.</p>

<p>The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.</p>

<p>The classes that an HTML element has assigned to it consists of all the classes returned when the value of the class attribute is split on spaces. (Duplicates are ignored.)</p>

<p>Assigning classes to an element affects class matching in selectors in CSS, the getElementsByClassName() method in the DOM, and other such features.</p>

<p>There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.</p>
</blockquote>

== Suggested wording==

Please add and sign suggestions, so that a composite may be produced at later date

* ...may be used for labelling, styling or indicating meaning" [[User:Pigsonthewing|Pigsonthewing]] 15:49, 11 August 2010 (UTC)
* ...may be used for labelling, styling or indicating semantics" [[User:Pigsonthewing|Pigsonthewing]] 15:51, 11 August 2010 (UTC)
* ...although classes allow content to be styled, they should be named to convey semantic meaning" [[User:Pigsonthewing|Pigsonthewing]] 15:52, 11 August 2010 (UTC)

==Prior discussion ==
* http://microformats.org/2005/10/19/more-than-styling

== Bug ==
* [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10346 W3C bug 10346]

Class

2010-08-11T15:52:43Z

Pigsonthewing: /* Suggested wording */ +1

Class

2010-08-11T15:51:57Z

Pigsonthewing: /* Suggested wording */ semantics

Class

2010-08-11T15:51:13Z

Pigsonthewing: /* Prior discussion */ bug

Class

2010-08-11T15:49:44Z

Pigsonthewing: a start

Main Page

2010-08-11T15:45:46Z

Pigsonthewing: class

Welcome to the WHATWG Wiki!

You can be a part of our community, making proposals for the next version of HTML5. This wiki is made available for you for drafting proposals, for writing essays, for keeping track of HTML-related issues, and so forth. Anyone can create an account and contribute content.

Before you begin, you may wish to read our [[WHATWG Wiki:Contribution Guidelines|contribution guidelines]].

==Purpose==
The purpose of the WHATWG Wiki is to create a place for WHATWG contributors to post and compile their own proposals and ideas regarding WHATWG specifications. The specifications themselves will not be available for editing via this wiki. However, ideas you post here may find their way into current and future WHATWG specifications.

== Main sections and Quick links ==
* [[FAQ]]
* [[Implementations]]
* [[What you can do]] — '''[[Reviewing HTML5|Help us review HTML5!]]
* [[Authoring|Using HTML 5 in your Web site]]
* [[HTML vs. XHTML]]
* [[HTML5 Presentations]]
* [[Spec coordination]]
* [[IDE]]
* [[Testsuite]]
* [[Registries]]

==WHATWG Specifications==
* [[HTML5]]
* [[Web Workers]]
* See also [[FAQ#What_are_the_various_versions_of_the_spec.3F|What are the various versions of the spec?]] in the FAQ.

==Communicating with the community==
The WHATWG community has several channels of communication:
* [http://www.whatwg.org/mailing-list Mailing lists]
* [http://blog.whatwg.org/ The blog], including [http://blog.whatwg.org/category/whats-next Mark Pilgrim's column "What's next in HTML5"]
* [http://www.w3.org/html/planet/ W3C's "HTML5 planet"]
* [http://forums.whatwg.org/ The forum]
* [[IRC]]
* [http://wiki.whatwg.org/ This wiki]

== Research and data ==
Research pertaining to and data on publishing behavior for various bits of markup, used to help drive decisions made in/for HTML5 for specific elements and attributes.
=== feature areas ===
* [[timed tracks]]
=== elements ===
* [[cite]]
* [[del]]
* [[input]]
* [[summary]]
* [[time]]

=== attributes ===
* [[alt]]
* [[charset]]
* [[class]]
* [[longdesc]]
* [[sandbox]]
* [[Table Summary|summary]]

=== meta ===
* [[Content-Language]]

These pages may also be of interest:

* [[Issue Discussion]]
* [[Feature Proposals]]
* [[Presentational elements and attributes]]

Time element

2010-08-11T15:00:04Z

Pigsonthewing: ,

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-ony; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]

=== 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...").
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [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)

=== 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...").
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [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 eras ("Edwardian", "bronze age", "Jurassic")".

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

<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>
</div>
* +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).

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

=== 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.
* …
</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 - 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 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 datetime 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.

=== simple nested time example improvement ===
We'd like to have our time 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 'datetime' 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.
* ...
</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.

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.

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://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)]