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
(→‎External links: HTML5 Doctor)
m (t)
Line 9: Line 9:


<div class="discussion">
<div class="discussion">
Opinions / discusion:
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 [[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 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)
Line 24: Line 24:


<div class="discussion">
<div class="discussion">
Opinions / discusion:
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 [[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 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)
Line 42: Line 42:


<div class="discussion">
<div class="discussion">
Opinions / discusion:
Opinions / discussion:
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])
* +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 "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/

Revision as of 20:36, 3 August 2010

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

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

Opinions / discussion:

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:

Calendar

The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per the emergent vCard 4 specification, to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using some as-yet-to-be-formulated CALSCALE type.

Opinions / discussion:

  • +1 Andy Mabbett (Per use cases in VCARDDAV, EDTF & TEI - see external links)
  • ...

Fuzzy dates

The time element should accept fuzzy (uncertain, approximate) dates and eras.

Opinions / discussion:

  • +1 Andy Mabbett (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
  • ...

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.

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.

External links

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