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

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

Time element: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(create section for syntax improvements that reduce DRY, moved nested time and am/pm proposals there, granularity contains *date* granularity proposals, include fuzzy dates in date granularity)
Line 1: Line 1:
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].
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].


==Granularity==
== Syntax improvements for reducing DRY violations ==
 
=== year only ===
The time element should accept just a year.
;ISO8601 syntax
:YYYY
;use case research
:http://microformats.org/wiki/birthday-examples#year_only
 
<div class="discussion">
Opinions / discussion:
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.
* -1 [[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.
* ...
</div>
 
=== year month only  ===
The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM
;use cases
:Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages), http://www.flickr.com/photos/tantek/archives/
:output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.
 
<div class="discussion">
Opinions / discussion:
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.
* -1 [[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.
* ...
</div>
 
=== year week only  ===
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently.  If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.
 
;reasoning
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code>
 
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.
 
<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
 
<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 &lt;time&gt; 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>
 
=== composite nested time elements ===
=== 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.
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.
Line 77: Line 7:
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].
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].


Simple example:
==== background ====
 
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:


Line 91: Line 20:
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).
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:
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:


Line 107: Line 37:
Disadvantage: the loss of the HTML5 time semantic.
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:
We'd like to have our time and date time separation as well, so this should work:


Line 113: Line 44:
   <span class="summary">I went to the cafe</span> at  
   <span class="summary">I went to the cafe</span> at  
   <time class="dtstart">
   <time class="dtstart">
     <time>18:00</time> on  
     <time>18:00:00</time> on  
     <time>2010-08-05</time>
     <time>2010-08-05</time>
   </time>.
   </time>.
Line 119: Line 50:
</nowiki></pre>
</nowiki></pre>


==== summary of updated datetime algorithm ====
In short: the algorithm for determining the "datetime" of a time element should:
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 an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
Line 126: Line 58:
Essentially, step 2 is added to enable composing nested child time elements.
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 &lt;time&gt; 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: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">
<div class="discussion">
Opinions / discussion:
Opinions / discussion:
Line 133: Line 101:
</div>
</div>


=== am pm and coarser time parsing ===
==== am pm and coarser time parsing ====
Right now time values inside a &lt;time&gt; element are required specify hours in 24 hour time.
Right now time values inside a &lt;time&gt; element are required specify hours in 24 hour time.


Line 151: Line 119:
* HHpm
* HHpm


Where "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").
Details:
* '''periods, whitespace, 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 HH of 12.''' for "am" values, HH of "12" is treated as "0". for "pm" values, HH of "12" is treated as "12".


When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.
Example (uses aforementioned composite nested time element proposal as well)
 
Example (uses aforementioned composite time proposal as well)


<pre><nowiki>
<pre><nowiki>
Line 170: Line 139:
Opinions / 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 &lt;time&gt; 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.
* +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 &lt;time&gt; 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]] - 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"? How does it internationalise? Also, see above for concerns over date formatting.
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
* ...
</div>
</div>


== Calendar scale ==
==== am pm FAQ ====
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.
===== noon and midnight =====
'''Question:''' How does this cater for "noon" and "midnight"?
 
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight".
 
===== ambiguity over 12am and 12pm =====
'''Question:''' How does this cater for the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?
 
'''Answer:''' Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.
 
===== am pm i18n =====
'''Question:''' How does it internationalise?
 
'''Answer:''' am and pm are (Latin origin) terms that are "used informally in most of the world."[http://en.wikipedia.org/wiki/12-hour_clock]
 
==Date granularity==
=== year only ===
The time element should accept just a year.
;ISO8601 syntax
:YYYY
;use case research
:http://microformats.org/wiki/birthday-examples#year_only
 
<div class="discussion">
Opinions / discussion:
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.
* -1 [[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.
* ...
</div>
 
=== year month only  ===
The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM
;use cases
:Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages), http://www.flickr.com/photos/tantek/archives/
:output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.
 
<div class="discussion">
Opinions / discussion:
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.
* -1 [[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.
* ...
</div>
 
=== year week only  ===
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently.  If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.
 
;reasoning
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code>


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


<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre>
<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>


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


<div class="discussion">
<div class="discussion">
Opinions / discussion:
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* +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 &lt;time&gt; 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>
</div>


== Fuzzy dates ==
=== 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")".
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")".


Line 197: Line 238:
**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.
**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].)
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)
* -1 [[User:Tantek|Tantek]] - I'm opposed to an abstract proposal without a precise syntax to evaluate that would solve the use cases / examples listed. I'm open to changing my opinion on this (to 0 or +1 depending on the simplicity/impact) if a more precise/complete syntax is provided.
</div>
</div>


==Specification ambiguities==
== Calendar scale ==
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.
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.
 
Example:
 
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre>
 
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.)


Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* -1 [[User:Tantek|Tantek]] - 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.
* …
</div>


==Choose different default date==
==Choose different default date==
Line 212: Line 265:
Opinions / 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?
* 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>
</div>
Line 246: Line 300:
* ...
* ...
</div>
</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.


== External links ==
== External links ==

Revision as of 16:57, 6 August 2010

Research, data, use cases, issues, and enhancements related to the HTML5 time element.

Syntax improvements for reducing DRY violations

composite nested time elements

A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.

This is intended as a cleaner way to provide functionality equivalent to the microformats value-class-pattern date and time values pattern.

background

Currently the <time> element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart"
        datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.
</p>

Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).

microformats value class pattern DRY advantage

With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <span class="dtstart">
     <span class="value">18:00</span> on 
     <span class="value">2010-08-05</span>
  </span>.
</p>

Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.

Disadvantage: the loss of the HTML5 time semantic.

simple nested time example improvement

We'd like to have our time and date time separation as well, so this should work:

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

summary of updated datetime algorithm

In short: the algorithm for determining the "datetime" of a time element should:

  1. check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
  2. check for nested <time> elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)
  3. use the complete contents of the <time> element as its datetime value.

Essentially, step 2 is added to enable composing nested child time elements.

applicability to microdata

All of the aforementioned advantages for microformats apply to microdata use of the <time> element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).

nested time example with datetime attribute

If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart">
     <time>18:00:00</time> on 
     <time datetime="2010-08-05">August 5th, 2010</time>
  </time>.
</p>

Advantage: The advantage here over the current time element is that the DRY violation is limited to only the date information (instead of date and time information), thus reducing the risk of data divergence due to duplication.

nested time example with two datetimes

If the publisher prefers to publish a "localized" form of times, they can do that as well:

<p class="vevent">
  <span class="summary">I went to the cafe</span> at 
  <time class="dtstart">
     <time datetime="18:00:00">6pm</time> on 
     <time datetime="2010-08-05">August 5th, 2010</time>
  </time>.
</p>

Advantage: The two separate 'datetime' attributes (containing just the time and just the date) are more human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.

The AM/PM proposal below further helps improve this example.

nested time discussion

Opinions / discussion:

  • +1 Tantek - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.
  • -1 Andy Mabbett - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.)
  • ...

am pm and coarser time parsing

Right now time values inside a <time> element are required specify hours in 24 hour time.

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 pattern:

  • HH:MM:SS - where HH is in 24 hour time.

This proposal expands this to:

  • HH:MM:SSam
  • HH:MM:SSpm
  • HH:MMam
  • HH:MMpm
  • HHam
  • HHpm

Details:

  • periods, whitespace, 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 HH of 12. for "am" values, HH of "12" is treated as "0". for "pm" values, HH of "12" is treated as "12".

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

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

Opinions / discussion:

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

am pm FAQ

noon and midnight

Question: How does this cater for "noon" and "midnight"?

Answer: This proposal does not address the (English) language specific terms of "noon" and "midnight".

ambiguity over 12am and 12pm

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

Answer: Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.

am pm i18n

Question: How does it internationalise?

Answer: am and pm are (Latin origin) terms that are "used informally in most of the world."[1]

Date granularity

year only

The time element should accept just a year.

ISO8601 syntax
YYYY
use case research
http://microformats.org/wiki/birthday-examples#year_only

Opinions / discussion:

year month only

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

ISO8601 syntax
YYYY-MM
use cases
Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages), http://www.flickr.com/photos/tantek/archives/
output equivalent of <input type="month">, see impedance match new date time inputs above.

Opinions / discussion:

year week only

The time element should accept just a year and a week number.

ISO8601 syntax
YYYY-WNN
use case research
no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
output equivalent of <input type="week">, see impedance match new date time inputs above.
reasoning
to provide the output equivalent of <input type="week">

See impedance match new date time inputs above.

Opinions / discussion:

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

month day only

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

ISO8601 syntax
--MM-DD
use case research
http://microformats.org/wiki/birthday-examples#month_and_day_only

Opinions / discussion:

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

Opinions / discussion:

  • +1 Andy Mabbett (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
    • Uncertainty possibly resolved by a "certainty" attribute:
      <time datetime="1855-06-18" certainty="3days">around 18 June 1855</time>
      <time datetime="1970-06" certainty="45days">summer 1970</time>
      (with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or:
      <time datetime="1963-12" certainty="circa">circa December 1963</time>
      with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
  • +1 Jim O'Donnell (Dates such as 'circa 1910' published on Flickr eg. The RNVR Training Ship 'Buzzard'… also a list of fuzzy dates for a set of photos.)
  • -1 Tantek - I'm opposed to an abstract proposal without a precise syntax to evaluate that would solve the use cases / examples listed. I'm open to changing my opinion on this (to 0 or +1 depending on the simplicity/impact) if a more precise/complete syntax is provided.

Calendar scale

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

Example:

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

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

Opinions / discussion:

  • +1 Andy Mabbett (Per use cases in VCARDDAV, EDTF & TEI - see external links)
  • -1 Tantek - 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.

Choose different default date

The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.

A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.

Opinions / discussion:

  • 0 (comment) Andy Mabbett - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?
  • -1 Tantek - I don't see any other default date as being significantly different.
  • ...

impedance match new date time inputs

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

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

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

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

Opinions / discussion:


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.


External links

Tag

Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time

Prior discussion

Resources