WHATWG Wiki - User contributions [en]

Time element

2010-08-05T10:47:08Z

Eatyourgreens:

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

== 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 inputs allow. In particular:

* 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>

== 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><time></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

<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><time></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)
** [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.
* ...
</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 <time> 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)
</div>

== Calendar ==
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 some as-yet-to-be-formulated CALSCALE type.

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* …
</div>

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

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
* +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].)
</div>

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

=== Prior discussion ===

* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]

=== Resources ===

* [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/proposals.html EDTF proposals] (use-cases)
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]

Time element

2010-08-05T10:40:21Z

Eatyourgreens:

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

== 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 inputs allow. In particular:

* 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>

== 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><time></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

<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><time></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)
** [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.
* ...
</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 <time> 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)
</div>

== Calendar ==
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 some as-yet-to-be-formulated CALSCALE type.

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

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

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
* ...
</div>

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

=== Prior discussion ===

* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]

=== Resources ===

* [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/proposals.html EDTF proposals] (use-cases)
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]

Time element

2010-08-05T10:39:29Z

Eatyourgreens:

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

== 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 inputs allow. In particular:

* 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>

== 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><time></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

<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><time></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)
** [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.
* ...
</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 <time> 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)
</div>

== Calendar ==
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 some as-yet-to-be-formulated CALSCALE type.

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

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

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
* ...
</div>

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

=== Prior discussion ===

* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]

=== Resources ===

* [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/proposals.html EDTF proposals] (use-cases)
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]