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
(add "year week only" proposal, crosslinks)
m (move my own mis-located comment)
Line 23: Line 23:
* ...
* ...
</div>
</div>


== year only ==
== year only ==
Line 56: Line 55:
* +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: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:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* +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: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.
* ...
* ...
Line 79: Line 77:
* ...
* ...
</div>
</div>


== month day only ==
== month day only ==
Line 93: Line 90:
* +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/
* +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)
* +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>



Revision as of 00:40, 6 August 2010

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

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>

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

Opinions / discussion:

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:

Calendar

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 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 ("summer 1970", "circa December 1963", "flourished 1580") and eras ("Edwardian", "bronze age", "Jurassic")".

Opinions / discussion:

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.

Tag

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

External links

Prior discussion

Resources