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
Line 345: Line 345:
* +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 [[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: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.
* 0 [[User:asbjornu|Asbjørn Ulsberg]] I think allowing this will quickly pollute and at worse make dates invalid as the data presented to humans become the same as that presented programmatically. When the user edits the date to say "the day before my birthday" instead of "2010-04-10", the date information is suddenly lost and the time element becomes invalid and void. I do see the need, but this is a hard one to get right.
* ...
* ...
</div>
</div>

Revision as of 14:00, 11 August 2010

Summary: Research, data, use cases, issues, and enhancements related to the HTML5 time 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 (and hopefully support) in the respective discussion sections.

Thanks for your consideration,

Tantek (and other proposal authors).


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

Date granularity

year only

The time element should accept just a year.

ISO8601 syntax
YYYY

year only use cases

use case research:

year only discussion

Opinions / discussion:

year only related posts

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

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

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

year month only

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

ISO8601 syntax
YYYY-MM

year month use cases

year month discussion

Opinions / discussion:

year month related posts

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

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

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

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

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

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

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

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

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

  • 2010-02-09 The time element (and microformats) blog post on HTML5 Doctor by Bruce Lawson - mentions:

    The only trouble with <time> is that the [sic] it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.

year week only

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

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

See impedance match new date time inputs above.

Opinions / discussion:

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

month day only

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

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

Opinions / discussion:

HTML5 internal consistency

impedance match new date time inputs

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

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

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

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

Opinions / discussion:

Proposals extending scope

Fuzzy dates

The time element should accept fuzzy (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and 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."[2]
Implemented, see [3], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.
2. ...

Opinions / discussion:

  • +1 Andy Mabbett (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
    • Uncertainty possibly resolved by a "certainty" attribute: 
      <time datetime="1855-06-18" certainty="3days">around 18 June 1855</time>
      <time datetime="1970-06" certainty="45days">summer 1970</time>
      (with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: 
      <time datetime="1963-12" certainty="circa">circa December 1963</time>
      with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
  • +1 Jim O'Donnell (Dates such as 'circa 1910' published on Flickr eg. The RNVR Training Ship 'Buzzard'… also a list of fuzzy dates for a set of photos.)
  • 0 (comments) Tantek - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:
    • certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)
    • certainty attribute takes an ISO8601 duration.
    • alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful) 
      • <range><time>2001</time>-<time>2003</time></range>
  • +1 Bruce Darcus says: "[While] I definitely think the use case is important...
    • "...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current draft idea in EDTF of doing "2000?" or "2000~"."
  • +1 Asbjørn Ulsberg I like the concept, but the syntax should be less verbose and more precise.
    • "Circa" can be indicated with a tilde prefix "~"
    • Ranges can use ISO-8601 time interval syntax, like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).

Calendar scale

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

Calendar scale example

Example: 

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

Calendar scale processing

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

Calendar scale use cases

Use case research:

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

Calendar scale discussion

Opinions / discussion:

  • +1 Andy Mabbett (Per use cases in VCARDDAV, EDTF & TEI - see external links)
  • 0 Tantek - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case does appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
  • …

Calendar scale related posts

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

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

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

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

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

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

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

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

Syntax improvements for reducing DRY violations

We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).

This experience yielded the microformats adoption of the DRY principle - don't repeat yourself - in application to (meta)dataformat designs and techniques.


The <time> element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element).

This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the <abbr> element.

Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related <abbr> problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).

http://microformats.org/wiki/value-class-pattern#Date_and_time_values

We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 <time> element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).

Accordingly, please consider the following <time> syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.


composite nested time elements

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

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

In short, instead of this (actual example derived from markup of blog post HTML5 watch by Jeremy Keith) 

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

We want to be able to do this: 

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

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

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

<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</time> on 
     <time>2010-08-05</time>
  </time>.
</p>

summary of updated datetime algorithm

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

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

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

applicability to microdata

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

nested time example with datetime attribute

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

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

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

nested time example with two datetimes

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

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

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

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

nested time discussion

Opinions / discussion:

  • +1 Tantek - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.
  • -1 Andy Mabbett - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) Update: Subsequent changes have addressed some of my concerns. The proposal to separate times from dates with datetime attributes is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.
  • ...

am pm and coarser time parsing

Right now time values inside a <time> element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.

In short, instead of this (actual example derived from markup of blog post HTML5 watch by Jeremy Keith, with nested time elements per previous proposal) 

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

We want to be able to do this: 

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

It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.

This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.

am pm syntax summary

In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).

In short, the current <time> element only allows for the following time syntax:

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

This proposal expands the allowed time syntax to:

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

am pm syntax details

  • periods, white-space, case-insensitivity. "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").
  • implied 00 minutes and seconds. When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;
  • handling of 12am and 12pm. "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).

simple am pm example

A simple example: 

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the

am pm example with nested time elements

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

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

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

am pm discussion

Opinions / discussion:

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

am pm FAQ

noon and midnight

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

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

am pm i18n

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

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

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: 

<div class="vevent">
 <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
  <span class="summary">Web 2.0 Conference</span>:
  <time class="dtstart" datetime="2007-10-05">October 5</time> -
  <time class="dtend" datetime="2007-10-20">19</time>,
  at the <span class="location">Argent Hotel, San Francisco, CA</span>
 </div>

(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)

This appears to have been copy/pasted from a past version of the hCalendar spec that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

Here is a suggested update: 

<div class="vevent">
 <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
 <span class="summary">Web 2.0 Conference</span>: 
 <time class="dtstart" datetime="2005-10-05">October 5</time>-
 <time class="dtend" datetime="2005-10-07">7</time>,
 at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see dtend issue for details).

Miscellaneous proposals

Choose different default date

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

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

Opinions / discussion:

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

Issues without specific proposals

Specification ambiguities

The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.

Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.


See Also

  • input - the input element, related proposals expanding upon the new datetime inputs.

External links

Tag

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

Prior discussion

Resources

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