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
(MusicBrainz could use <time>)
(2 new sections)
Line 66: Line 66:
</div>
</div>


==Specification ambiguities==
Nowhere does the specification say times and dates should be in the ISO-8601 format. Failure to say if, and to what extent that specification is adopted leads to ambiguities such as:
*Is 20100701 a valid date?
*Is 1972-06-30T23:59:'''60''' a valid date & time?
The statement that valueAsDate  IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date implies that ISO-8601 is '''not''' adopted, since that date has no special significance within the ISO 8601 spec.
==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 ==
== External links ==
* [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/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)

Revision as of 13:22, 13 July 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 / discusion:

year month only

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

ISO8601 syntax
YYYY-MM

Opinions / discusion:

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 / discusion:

Calendar

The time element should accept a calendar scale (default is GREGORIAN) per the emergent vCard 4 specification, to facilitate the mark-up of non-Gregorian (e.g. Julian) dates.

Opinions / discussion:

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

Specification ambiguities

Nowhere does the specification say times and dates should be in the ISO-8601 format. Failure to say if, and to what extent that specification is adopted leads to ambiguities such as:

  • Is 20100701 a valid date?
  • Is 1972-06-30T23:59:60 a valid date & time?

The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date implies that ISO-8601 is not adopted, since that date has no special significance within the ISO 8601 spec.

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