WHATWG Wiki - User contributions [en]

Cite element

2014-11-14T17:35:14Z

Tantek: /* Speaker */ spec allows for it now

Research, data, use cases, issues, and enhancements related to the HTML5 <code>cite</code> element.

== Speaker ==

<ins datetime="2014-11-14">Update 2014-11-14: The HTML spec has been changed to allow use of <cite> to refer to a speaker, and even includes an example of it: http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-cite-element</ins>

The cite element has been used (and recommended to be used) to refer to speakers in a conversation, or individuals when quoting them, thus HTML5 should explicitly permit and encourage this use.

This section serves to document both uses in the wild, and long-standing recommendations/documentations thereof.

=== Examples in the Wild ===
* 2003-08-23: <cite>[http://diveintomark.org/archives/2003/08/29/semantics Won’t somebody please think of the gerbils?]</cite> by <cite>[http://diveintomark.org/ Mark Pilgrim]</cite>: <blockquote>I mark up names of people I link to (like in the list above) with the CITE tag, and I have a script that runs every night that aggregates those tags and creates posts by citation.</blockquote>
* [http://www.geekinthepark.co.uk/transcripts/2008/brian-cant.html transcript of the presentation “What Brian Cant Never Taught You About Metadata”, by Drew McLellen] (this is from a template I provided the transcription company; all others are similar structure. brucel)
* Many blog posts on [http://adactio.com/journal/ adactio.com], e.g <cite>[http://adactio.com/journal/1398/ Blame]</cite> from 2008-01-09: <blockquote>...something Bruce Sterling said at last year’s South by Southwest...</blockquote>
* Default WordPress theme ("Kubrick") uses cite for name of commenters. That's approx 46 bajillion instances.
* The transcripts for comics (#34 and onward) at [http://www.cssquirrel.com/ CSSquirrel]. The links to the transcripts are hidden from sighted users, one example is: [http://www.cssquirrel.com/comicscripts/script35.htm Transcript #35 2009-09-08]
* 2005-05-16: Speakers in this <cite>[http://erikanderica.org/erik/work/lazarus/playtext/ Towneley Lazarus play]</cite> edition are identified using CITE.
* [http://igofigure.com/page/testimonials/ Testimonials on the website for Go Figure Inc.] use cite to denote the names/locations of the people who provided the testimonial
* [http://guineylaw.com/testimonials/ The Law Offices of Thomas G Guiney] uses cite to mark up the names of speakers for testimonial quotes.
* [http://2009.dconstruct.org/podcast/makeitso/ Podcast transcript] from dConstruct 2009 ([http://2009.dconstruct.org/podcast/ more])
* Various "conversations"/transcripts at [http://peterjanes.ca/blog/ Petroglyphs], e.g. [http://peterjanes.ca/blog/2008/04/04/bang/ dialogue], and [http://peterjanes.ca/blog/wp-content/themes/petroglyphs/style.css CSS classes defined for terms, titles, etc.] ([http://peterjanes.ca/2005/citations/# XMDP])
* any article at Einfach für Alle (major german accessibility resource), e.g. [http://www.einfach-fuer-alle.de/artikel/ueberschriften-strukturen-in-html/] (see sidebar, 4th box from top labelled "mehr dazu:") uses cite to mark up authors' names
* any articles on [http://www.la-grange.net/ La Grange] with a quote from a book or poem, and in addition any kind of references to a blog post. cite class="auteur" and cite class="title" for author and title respectively.
* 2011-06-07: Wikipedia marks the autor inside a blockquote with the cite-Element: [http://en.wikipedia.org/wiki/Template:Quotation en Wikipedia] ([http://toolserver.org/~jarry/templatecount/index.php?lang=en&name=Template%3AQuotation#bottom 12379 uses]), [http://de.wikipedia.org/wiki/Wikipedia:Zitate#Blockzitate de Wikipedia] ([http://toolserver.org/~jarry/templatecount/index.php?lang=de&name=Zitat#bottom 24922 uses])

=== Documentation ===
* 1998-04-24 <cite>[http://www.w3.org/TR/1998/REC-html40-19980424/struct/text.html#h-9.2.1 HTML 4.0 REC]</cite> <blockquote>Contains a citation or a reference to other sources.</blockquote><blockquote><p>As <CITE>Harry S. Truman</CITE> said,<br><Q lang="en-us">The buck stops here.</Q></p><p>More information can be found in <CITE>[ISO-0000]</CITE>.</p></blockquote>
* 1999-12-24 <cite>[http://www.w3.org/TR/html401/struct/text.html#edef-CITE HTML 4.01 REC]</cite> (same definition and examples as quoted above).
* 2005-03-13: <cite>[http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]</cite> presentation (to an overflowing room at SXSW Interactive 2005 in Austin, TX) specifically, [http://tantek.com/presentations/2005/03/elementsofxhtml/#slide10 slide10 and following] document blog quote markup, and [http://tantek.com/presentations/2005/03/elementsofxhtml/#slide19 slide 19 and following] document conversation markup.
** 2005-09-29: update: <cite>[http://tantek.com/presentations/2005/09/elements-of-xhtml/ The Elements of Meaningful XHTML]</cite> presentation (to a packed room at Web Essential 05 in Sydney Australia) again [http://tantek.com/presentations/2005/09/elements-of-xhtml/#slide10 slide 10 and following], and [http://tantek.com/presentations/2005/09/elements-of-xhtml/#slide34 slide 34 and following] respectively.
* ...

=== Counter-arguments ===
==== original intent of cite element ====
* 2007-06-07 <cite>Dan Connolly</cite>, Editor of HTML 2.0, said in IRC that <blockquote cite="http://krijnhoetmer.nl/irc-logs/html-wg/20070607#l-797"><cite> was supposed to capture the chicago-manual-of-style idiom for titles of works. I have lost track of what it means these days.</blockquote>
** This may have been the original intent (original theoretical purity), however, based on the example in the HTML4 spec(s) and adoption by the web community over the past 10+ years (see above examples in the wild), it makes more sense to define the <cite> element per actual usage (preferring authors), rather than original intent (theoretical purity), per the [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies priority of constituencies HTML design principle]. - [[User:Tantek|Tantek]] 22:18, 13 August 2010 (UTC)

* "DanC said allowing <nowiki><cite></nowiki> for speakers was a bug in HTML 4 that happened because he was asleep at the wheel."
** Regardless of what DanC as a <em>specifier</em> may have intended, the authors have widely adopted the usage of cite for speakers, and thus since authors are considered over specifiers (per above-referenced design principle), we should prefer author usage over original specifier intent.

==== speakers are not italicized typically ====
* "Since speakers aren't italicized typically, using <nowiki><cite></nowiki> for them doesn't really make sense. "
** This sounds like either an argument from presentation, which seems backwards, as semantics should be determined first, and then authors can style semantics however they wish, or it's an argument from default presentation implementation, in which case once again per [http://www.w3.org/TR/html-design-principles/#priority-of-constituencies priority of constituencies HTML design principle], since authors are considered over implementers, we should respect author usage of cite for speakers over any particular implementer opinion of what cite should do or look like.
***The Design Principles don't support the notion of determining semantics first. In fact, the Design Principles were carefully drafted not to treat semantics as having any value on their own right but only as a means to a useful end (such as Device Independence or Accessibility). As for considering authors over implementors or specifiers, we should consider whether an author who hasn't been exposed to advocacy that tries to rationalize the feature set of HTML4 would find a need to mark up speakers in a way that italicizes by default and required additional work to un-italicize as opposed to not marking up speakers at all all using the <code>b</code> element to bold speakers where required by a newspaper-like house style. That is, what authors do after having been exposed to advocacy is bad evidence for determining the needs the authors would have on their own initiative.

=== Opinions ===
Opinions on whether HTML5 should explicitly permit and encourage use of the cite element to refer to speakers in a conversation, or individuals when quoting them:
<div class="discussion">
* +1 [http://www.zeldman.com/superfriends/ HTML5 Super Friends], specifically [http://www.zeldman.com/superfriends/guide/#cite cite element: review of data].
* +1 [[User:Tantek|Tantek]]
* +1 [[User:Adactio|Jeremy Keith]]
* +1 [[User:Brucel|Bruce Lawson]], article agreeing with Tantek, July 06 [http://www.brucelawson.co.uk/2006/breaking-news-w3c-specs-are-not-word-of-god/ Breaking news: w3c specs are not the Word of God]
* +1 [[User:Cssquirrel|Kyle Weems]]
* +1 [[User:Erikvorhes|Erik Vorhes]]
* +1 [[User:Themattharris|Matt Harris]]
* -0 [[User:EdwardOConnor|EdwardOConnor]]
* +1 [[User:Xanthir|Tab Atkins Jr.]]
* +1 [http://www.rachaelmoore.name/web-design/html-web-design/citing-in-html5-cite-attribute-and-cite-tag/ Citing in HTML5] by Rachael L. Moore
* +1 [[User:Tcaspers|Tomas Caspers]]
* +1 [[User:NickFitz|NickFitz]]
* +1 [[User:Asbjornu|Asbjørn Ulsberg]]
* +1 [http://statichtml.com/2009/html5-cite-element.html HTML5's <cite> element: what is it good for?] by Steve Webster
* +1 [[User:Urlyman|Jonathan Schofield]]
* +1 [[User:Dalizard|Dimitar Haralanov]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:Tjameswhite|Tim White]]
* +1 [[User:Tswicegood|Travis Swicegood]]
* -1 [[User:Hsivonen|Henri Sivonen]]
* +1 [[User:KevinMarks|Kevin Marks]]
* +1 [[User:Stefsull|Stephanie (Sullivan) Rewis]]
* +1 [[User:Kroc|Kroc Camen]]—See my [http://camendesign.com/abbr_redux article on abbr/dfn/cite usage]—Cite is “for giving credit”
* +1 [[User:Suit|Suit]] because examples on various sites get this wrong (see [http://www.quackit.com/html_5/tags/html_cite_tag.cfm] for example) - its just confusing.
</div>

=== articles on speaker cite ===
Articles supporting the use of the cite element for marking up speakers:
* <cite>[http://24ways.org/2009/incite-a-riot 24 Ways: Incite A Riot]</cite>, 2009-12-11, by Jeremy Keith

=== speaker cite FAQ ===
Frequently Asked Questions about using the cite element for marking up speakers.

==== how do you connect the speaker cite to what was said ====
'''Question:''' How could we connect the speaker, CITE to what was said, Q, without nesting? Perhaps using FOR, as in form labels:<pre><nowiki><cite for="good">Andy Mabbett</cite> said <q id="good">This is good</q>.</nowiki></pre>On the other hand, if we reverse that we could have a many-to-one relationship:<pre><nowiki><cite id="andy">Andy Mabbett</cite> said <q for="andy">This is good</q></nowiki> and later said <q for="andy">This is better</q>.</nowiki></pre>

'''Answer:''' The existing [http://www.w3.org/TR/html401/struct/text.html#adef-cite-Q 'cite' attribute] on the <q> and <blockquote> elements can be used for this, in HTML4 and later:

<pre style="background:#efe"><nowiki>
<cite id="andy">Andy Mabbett</cite> said
<q cite="#andy">This is good</q>
and later said
<q cite="#andy">This is better</q>.
</nowiki></pre>

=== speaker cite related ===
* [[FAQ#The_.3Ccite.3E_element_should_allow_names_of_people_to_be_marked_up|WHATWG FAQ re cite and names of people]]

== references ==
* [http://www.w3.org/TR/html401/struct/text.html#edef-CITE HTML 4.01 definition of the CITE element]

[[Category:Proposals]]

URL

2014-10-06T22:15:23Z

Tantek: add Requests and Issues / How to compare URLs

{{CC0 page}}

This documents research and notes around URLs for the [http://url.spec.whatwg.org/ URL standard].

==Implementations==

* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/KURL.cpp
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/KURLWTFURL.cpp
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/KURLGoogle.cpp
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/network/DataURL.cpp (data URLs)
* http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp
* http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/nsJSProtocolHandler.cpp (javascript URLs)
* http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prnetdb.c#1544 (IPv6)

==Tests==

* https://github.com/cweb/iri-tests

Variants of the following code (runs in Live DOM Viewer) are useful to test which code points are URL escaped in browsers:
<pre><!DOCTYPE html>
<script>
var a = document.createElement("a")

i = 0
cp = 0x100

while ( i < cp ) {
a.href = "http://x" + String.fromCharCode(i) + "@x/"
if(a.href.length != "http://x)@x/".length) {
w(a.href)
}
i++
}
</script></pre>

==Parsing==

* https://github.com/annevk/url/blob/master/url.js
* http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0305.html has notes on file URLs in Gecko.

==JavaScript libraries==

For improving the API we might want to take inspiration from:

* http://medialize.github.com/URI.js/
* https://github.com/joyent/node/blob/master/doc/api/url.markdown
* https://github.com/bestiejs/punycode.js (just Punycode)

==Schemes==

Apart from the scheme-types listed below, the URL Standard identifies "relative schemes", used for parsing a URL into a parsed URL.

=== Purpose-specific schemes ===

URL schemes are purpose-specific schemes if they only work in one context. These only work for WebSocket:

* ws
* wss

=== Fetch schemes ===

URL schemes are resource schemes if fetching the URL results in either a network error or a resource with associated MIME type (potentially sniffed).

; ftp
; http
; https : These all can be used by the corresponding protocol directly.
; file : Needs platform-specific interpretation and mapping to a resource on a the local file system.
; data : Needs its resource and MIME type information retrieved from its scheme data/query.
; blob
; about : The resource is effectively the result of passing scheme data to a hash table (not sure if case-sensitive or not; definitely no percent decoding). Query and fragment can be used by the resource.

(The same-origin definition should maybe account for about/blob/data.)

=== Navigate schemes ===

* The "fetch schemes" -> use "fetch"
* javascript
* Not the "purpose-specific schemes" -> error
* All other schemes (including "external schemes")

=== External schemes ===

Depending on the context, schemes not listed above will either launch an external application or result in a network error. Examples:

* mailto
* skype

==IDNA==

=== Definitions ===

* IDNA2003+: IDNA2003 with Unicode updated to the latest version. (So not NFKC from Unicode 3.2., although [http://docs.python.org/2/library/unicodedata.html#unicodedata.ucd_3_2_0 Python might do that]... ) Restrictions on display might be in place.
* IDNA2008+: IDNA2008 with [http://tools.ietf.org/html/rfc5895#section-2 RFC 5895 section 2] mapping and IDNA2003 domain label separators. Display is restricted to IDNA2008, lookup is unrestricted (everything gets Punycoded).

=== Implementations ===

* IDNA2003+: Safari, Chrome, Firefox
** Changing, see e.g. https://codereview.chromium.org/23642003#msg4
* IDNA2008+: Internet Explorer?

=== Tests ===

* http://mathias.html5.org/tests/url/idna2003-separators/ IDNA2003 domain label separators are supported everywhere

=== Algorithms ===

* ToLabels(domain string) -> ASCII-label list (empty label at the end signifies trailing dot) or failure.
* ToASCII(Unicode-label) -> ASCII-label.
* ToUnicode(ASCII-label) -> Unicode label.

(For convenience maybe ToASCII and ToUnicode should accept lists too.)

=== UI ===

Note that this has potential security implications too, but does not matter for interoperability.

* http://www.chromium.org/developers/design-documents/idn-in-google-chrome (also includes summary for other browsers)
* https://wiki.mozilla.org/IDN_Display_Algorithm
* http://www.alvestrand.no/pipermail/idna-update/2011-December/date.html (has lots of background discussion)
* https://bugs.webkit.org/show_bug.cgi?id=126627

=== Notes ===

* Input to DNS is a byte array. (This means that "_" and byte 0x03 can be valid input. Not sure whether "." works within a label. Higher than 0x7F cannot happen if IDNA is used.)
* DNS is of course not the only system in place, but browsers do not seem to care as far as mapping is concerned.
* http://www.unicode.org/mail-arch/unicode-ml/y2011-m07/0036.html http://www.unicode.org/mail-arch/unicode-ml/y2011-m07/0057.html
* http://tools.ietf.org/html/rfc6055 has historical deliberations

[[Category:Spec coordination]]

== Requests and Issues ==
=== How to compare URLs ===
There is at least one specification (being implemented) that needs a reference for how to compare URLs for equivalency.
* http://microformats.org/wiki/representative-hcard-parsing

Hence, request:

New section/feature in the URL spec:

"How to compare URLs"

with something like: "parse them first and then compare the serialization"

See: http://krijnhoetmer.nl/irc-logs/whatwg/20141006#l-843
for background / discussion.

MetaExtensions

2013-12-12T04:13:53Z

Tantek: make intro more readable, add MikeSmith instructions for getting validator(s) updated

This page lists the allowed extension values for the name="" attribute of the <meta> element in HTML5.

You may add your own values to this list, which makes them legal HTML5 metadata names.

We ask that you:
* '''avoid redundancy''' - if someone has already defined a name that does roughly what you want, please reuse it.
* '''be sure to include ''all'' the items''' [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names required by the spec] ''including a link to a specification'' that specifies the keyword ''as an HTML meta keyword''. If a proposal lacks a specification and a version in a complete specification exists, the latter is to be preferred.

Note that URL-valued properties must not be registered as meta names but should be registered as [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions rel keywords] instead.

Also note that changes to this registry may not be reflected in validators in real time.

Changes to this registry may not be reflected in validators in real time.

If you add a meta name value to this table and you want it supported in the validator(s), you need to either [http://bugzilla.validator.nu/ open a validator bug] or e-mail the [mailto:www-validator@w3.org www-validator@w3.org] list to ask that it be added and reference your change to this page.

== Registered Extensions ==

{| class="wikitable sortable"
! Keyword
! Brief description
! Link to specification
! Synonyms
! Status

|-valign="top"
| aafc.subject
| The topic of the resource within the Department of Agriculture and Agri-Food Canada
|
|
| Proposal

|-valign="top"
| rights
| Extra Copyright info used by Direkt SPEED and others
|
|
| Proposal

|-valign="top"
| og:site_name
| The Name of the site for OpenGraph Facebook
|
|
| Proposal

|-valign="top"
| AGLSTERMS.act
| A specific piece of legislation which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.accessibility
| A statement indicating the accessibility characteristics of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.accessMode
| Perceptual mode for the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.aggregationLevel
| The level of aggregation of the described resource - an 'item' or a 'collection'.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.availability
| How the resource can be obtained or accessed, or contact information. Primarily used for offline resources to provide information on how to obtain physical access to the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.case
| A specific piece of case law which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.category
| The generic type of the resource being described - a 'service', 'document' or 'agency'.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.dateLicensed
| Date a license was applied or became effective.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.documentType
| The form of the described resource where the value of category is‘document’. Document is used in its widest sense and includes resources such as text, images, sound files and software.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.function
| The business function to which the resource relates. Functions are the major units of activity which organisations pursue in order to meet the mission and goals of the organisation.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.isBasisFor
| A related resource that is a performance, production, derivation, translation or interpretation of the described resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.isBasedOn
| A related resource of which the described resource is a performance, production, derivation, translation or interpretation.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.jurisdiction
| The name of the political/administrative entity covered by the described resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.mandate
| A specific legal instrument which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.protectiveMarking
| A protective marking applied to the described resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.regulation
| A specific regulation which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.serviceType
| The form of the described resource where the value of category is ‘service'.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| alexaverifyid
| Used to verify ownership of Alexa Search
| [http://www.alexa.com/faqs/?p=188 Alexa FAQ About this meta attribute Reference]
|
| Proposal

|-valign="top"
| Copyright
| Used to verify Copyright of the Website
|
| <code><meta name="rights"></code> '''(already proposed but rejected because of missing spec)'''
<code><meta name="dcterms:rights"></code>
| Proposal

|-valign="top"
| Revisit
| Used to check revisit of the Website
|
| Possibly <code><meta name="revisit-after"></code>,
cookies
| Proposal

|-valign="top"
| Abstract
| Used to check the content of the Website
|
| <code><meta name="dcterms:abstract"></code>
<code><meta name="dcterms:description"></code>
| Proposal

|-valign="top"
| page-topic
| Used to check the page topic or category of the Website
|
| standard <code><meta name="description"></code>
or <code><meta name="keywords"></code>
| Proposal

|-valign="top"
| audience
| Used to clarify the audience or category page traffic for the Website
|
| <code><meta name="dcterms:audience"></code>
Already existing, but '''rejected because of missing spec'''
| Proposal

|-valign="top"
| tysontcsverid
| Used to verify ownership of Website for TCS webmaster tools
| [http://www.tysontcs.co.uk/Veridspec.html Livechat About this meta attribute Reference]
|
| Proposal

|-valign="top"
| apple-itunes-app
| Promoting Apps with Smart App Banners
| [http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html Safari Web Content Guide]
|
| Proposal

|-valign="top"
| apple-mobile-web-app-capable
| Sets whether a web application runs in full-screen mode.
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]
| mobile-web-app-capable (also could maybe be assumed when <code>application-name</code> is set?)
| Proposal

|-valign="top"
| apple-mobile-web-app-status-bar-style
| Sets the style of the status bar for a web application.
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]
|
| Proposal

|-valign="top"
| apple-touch-fullscreen
| Makes WebApp Fullscreen (With iPhone 5 Support)
| No specification yet
|
| Proposal

|-valign="top"
| apple-mobile-web-app-title
| Sets the title of the application when added to the homescreen on iOS6+
| No specification yet
|
| Proposal

|-valign="top"
| application-url
| '''Start URL of web apps in Google Chrome'''
The "application-url" meta tag can be used to specify the start URL of pinned web apps in Google Chrome.
<meta name="application-url" content="https://gmail.com/">
| [http://www.google.com/chrome/intl/en/webmasters-faq.html#customshortcuts Google Chrome Webmaster FAQ] [http://code.google.com/p/chromium/issues/detail?id=40010#c1 Chromium issue response]
|
| Proposal

|-valign="top"
| baiduspider
| Synonym of <code>robots</code> for targeting Baidu only.
| [http://www.baidu.com/search/robots_english.html Baidu documentation]
|
| Proposal

|-valign="top"
| bitcoin
| A Bitcoin address
| [https://en.bitcoin.it/wiki/Address Bitcoin address on the Bitcoin wiki]
|
| Proposal

|-valign="top"
| cfia.gdr.include
| Canadian Food Inspection Agency Guidance Document Repository Page
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| cfia.gdr.program
| Canadian Food Inspection Agency Guidance Document Repository Page Program
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| cfia.gdr.commodity
| Canadian Food Inspection Agency Guidance Document Repository Page Commodity
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| cfia.gdr.activity
| Canadian Food Inspection Agency Guidance Document Repository Page Activity
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| citeseerxbot
| Synonym of <code>robots</code> for targeting CiteSeerX only.
| [http://csxstatic.ist.psu.edu/submit CiteSeerX Submit Documents] <small>'If you do not want your documents crawled by CiteSeerX, please use a robots.txt to disallow our crawler named "citeseerxbot"'</small>, [http://csxstatic.ist.psu.edu/about/crawler CiteSeerX Crawler]
|
| Proposal

|-valign="top"
| collection
| To replace the obsolete dc:collection. A collection is described as a group, an aggregation of topics Used to describe the top-level content of XHTML documents. These appear in your META tags showing a group of subject. Website Taxonomy improve classification for search engine analysis and semantic communication with a description language content.

<meta name="collection" content="MetaExtensions" />
<meta name="subject" content="topics, thesaurus, Meta Tag, header, semantic" />
| [http://www.trucsweb.com/tw/]
|
| Proposal

|-valign="top"
| csrf-param
| Cross-site request forgery protection parameter for Ruby on Rails
| [http://apidock.com/rails/ActionView/Helpers/CsrfHelper/csrf_meta_tag Rails API]
|
| Proposal

|-valign="top"
| csrf-token
| Cross-site request forgery protection token for Ruby on Rails
| [http://apidock.com/rails/ActionView/Helpers/CsrfHelper/csrf_meta_tag Rails API]
|
| Proposal

|-valign="top"
| da_anonymiseIP
| Defines anonymiseIP parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactCompany
| Defines the contactCompany of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactEmail
| Defines the contactEmail of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactFirstName
| Defines the contactFirstName of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactLastName
| Defines the contactLastName of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactName
| Defines the contactName of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactTelephone
| Defines the contactTelephone of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_conversionCurrency
| Defines the conversionCurrency of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_conversionId
| Defines the conversionId of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_conversionValue
| Defines the conversionValue of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_goalCurrency
| Defines the goalCurrency of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_goalId
| Defines the goalId of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_goalValue
| Defines the goalValue of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_interactionSelector
| Defines the interactionSelector parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageRole
| Defines the role of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageTaxonomy
| Defines the taxonomy of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageTitle
| Defines the pageTitle of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageVersion
| Defines the pageVersion of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_sessionId
| Defines the sessionId parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_userId
| Defines the userId parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| dc.date.issued
| Date of publication for Google News. The format of the content is YYYY-MM-DD or YYYY-MM-DDThh:mm:ssTZD.
It must be accompanied by a <code><link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"></code> element
| [http://www.google.com/support/news_pub/bin/answer.py?answer=93994 Google News documentation]
| <code>dcterms.issued</code> (former <code><time pubdate></code> no longer considered due to the abort of <code>@pubdate</code>)
| Proposal

|-valign="top"
| dc.language
| A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646].
It must be accompanied by a <code><link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-language DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| Redundant with the <code>lang</code> attribute on the
<code>html</code> element. (Browsers pay attention to the <code>lang</code> attribute but not <code>dc.language</code>)
| Proposal

|-valign="top"
| dcterms.abstract
| A summary of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-abstract DCMI
Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| <code><meta name="description"></code>
| Proposal

|-valign="top"
| dcterms.accessRights
| Information about who can access the resource or an indication of its security status.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accessRights DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.accrualMethod
| The method by which items are added to a collection.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualMethod DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.accrualPeriodicity
| The frequency with which items are added to a collection.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualPeriodicity DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.accrualPolicy
| The policy governing the addition of items to a collection.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualPolicy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.alternative
| An alternative name for the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-alternative DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.audience
| A class of entity for whom the resource is intended or useful.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-audience DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.available
| Date (often a range) that the resource became or will become available.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-available DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.bibliographicCitation
| A bibliographic reference for the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-bibliographicCitation DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML attribute <code>cite</code>
| Proposal

|-valign="top"
| dcterms.collection
| An aggregation of resources.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#dcmitype-Collection DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.conformsTo
| An established standard to which the described resource conforms.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-conformsTo DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.contributor
| An entity responsible for making contributions to the content of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-contributor DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.coverage
| The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-coverage DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.created
| Date of creation of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-created DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.creator
| An entity primarily responsible for making the resource. Examples of a Creator include a person, an organization, or a service.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-creator DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| In some cases redundant with the HTML built-in keyword <code>author</code>
| Proposal

|-valign="top"
| dcterms.date
| A point or period of time associated with an event in the lifecycle of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-date DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.dateAccepted
| Date of acceptance of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-dateAccepted DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.dateCopyrighted
| Date of copyright.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-dateCopyrighted DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.dateSubmitted
| Date of submission of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-dateSubmitted DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.description
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-description DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in keyword <code>description</code>
| Proposal

|-valign="top"
| dcterms.educationLevel
| A class of entity, defined in terms of progression through an educational or training context, for which the described resource is intended.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-educationLevel DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.extent
| The size or duration of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-extent DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.format
| The file format, physical medium, or dimensions of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-format DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| To be limited to dimensions information. File format for the document is to be determined by server. Linked resources can be described by <code>type</code> attribute.
| Proposal

|-valign="top"
| dcterms.hasFormat
| A related resource that is substantially the same as the pre-existing described resource, but in another format.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-hasFormat DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.hasPart
| A related resource that is included either physically or logically in the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-hasPart DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.hasVersion
| A related resource that is a version, edition, or adaptation of the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-hasVersion DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.identifier
| An unambiguous reference to the resource within a given context.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-identifier DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.instructionalMethod
| A process used to engender knowledge, attitudes and skills, that the described resource is designed to support.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-instructionalMethod DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.isFormatOf
| A related resource that is substantially the same as the described resource, but in another format.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isFormatOf DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.isPartOf
| A related resource in which the described resource is physically or logically included.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isPartOf DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.isReferencedBy
| A related resource that references, cites, or otherwise points to the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isReferencedBy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.isReplacedBy
| A related resource that supplants, displaces, or supersedes the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isReplacedBy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.isRequiredBy
| A related resource that requires the described resource to support its function, delivery, or coherence.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isRequiredBy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.issued
| Date of formal issuance (e.g., publication) of the resource. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.)
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-issued DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| (former <code><time pubdate></code> no longer considered due to the abort of <code>@pubdate</code>)
| Proposal

|-valign="top"
| dcterms.isVersionOf
| A related resource of which the described resource is a version, edition, or adaptation.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isVersionOf DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.language
| A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646].
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-language DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| Redundant with the <code>lang</code> attribute on the <code>html</code> element. (Browsers pay attention to the <code>lang</code> attribute but not <code>dcterms.language</code>)
| Proposal

|-valign="top"
| dcterms.license
| A legal document giving official permission to do something with the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-license DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML <code><link></code> element with the keyword <code>"license"</code> as value of the <code>rel</code> attribute.
| Proposal

|-valign="top"
| dcterms.mediator
| An entity that mediates access to the resource and for whom the resource is intended or useful.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-mediator DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.medium
| The material or physical carrier of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-medium DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.modified
| Date on which the resource was changed. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.)
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-modified DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.provenance
| A statement for any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-provenance DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.publisher
| An entity responsible for making the resource available.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-publisher DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.references
| A related resource that is referenced, cited, or otherwise pointed to by the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-references DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| <code>cite</code> attribute on specific quotes, if any.
| Proposal

|-valign="top"
| dcterms.relation
| A related resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-relation DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| If the relation comes from an internal reference or quote, <code>dcterms.references</code> should be preferred.
| Proposal

|-valign="top"
| dcterms.replaces
| A related resource that is supplanted, displaced, or superseded by the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-replaces DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.requires
| A related resource that is required by the described resource to support its function, delivery, or coherence.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-requires DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.rights
| Information about rights held in and over the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-rights DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML <code><link></code> element with the keyword <code>"license"</code> as value of the <code>rel</code> attribute, if referring to a legal license format.
| Proposal

|-valign="top"
| dcterms.rightsHolder
| A person or organization owning or managing rights over the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-rightsHolder DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.source
| A related resource from which the described resource is derived.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-source DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code> if documents are different versions. Otherwise, <code>cite</code> attribute.
| Proposal

|-valign="top"
| dcterms.spatial
| Spatial characteristics of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-spatial DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.subject
| The topic of the resource.
| [http://dublincore.org/documents/dcmi-terms/#terms-subject DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in keywords <code>description</code> or <code>keywords</code>
| Proposal

|-valign="top"
| dcterms.tableOfContents
| A list of subunits of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-tableOfContents DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in keywords <code>description</code> or <code>keywords</code>. Otherwise, a <code>details-summary</code> model which would provide user-readable information.
| Proposal

|-valign="top"
| dcterms.temporal
| Temporal characteristics of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-temporal DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.title
| A name given to the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-title DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in element <code>title</code> (not to be confused with <code>@title</code> attributes specific to each element)
| Proposal

|-valign="top"
| dcterms.type
| The nature or genre of the resource.
| [http://dublincore.org/documents/dcmi-terms/#terms-type DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.valid
| Date (often a range) of validity of a resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-valid DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| designer
| Credits the designer(s) responsible for the visual presentation of a website.
| [https://sites.google.com/site/metadesignerspec/ Documentation]
|
| Proposal

|-valign="top"
| entity
| Allows for definitions of XML-style entities for substitution of references (defined as specially-named elements (e.g., use of data element and/or data-* attribute) or script tags) via inclusion of a JavaScript library. Library also supports inclusion of additional meta element entity definitions via iframe documents.
| [https://github.com/brettz9/js-css-entities Documentation]
|
| Proposal

|-valign="top"
| EssayDirectory
| Defines a custom description of websites listed in EssayDirectory.<br>Example:
<meta name="EssayDirectory" content="Helping students find legitimate essay services.">
| [http://essaydirectory.com/privacy-terms/#EssayDirectory_MetaExtension Documentation]
|
| Proposal

|-valign="top"
| fdse-description
| Tag used by FDSE search software, allows different description to be displayed in fdse results to that shown in description
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| fdse-index-as
| Tag used by FDSE search software, allows FDSE to index a page as url described here
| [http://www.xav.com/scripts/search/help/1014.html]
|
| Proposal

|-valign="top"
| fdse-keywords
| Tag used by FDSE search software, allows different keywords to be used by FDSE to keywords tag
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| fdse-refresh
| Tag used by FDSE search software, allows FDSE to ignore refresh meta tags
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| fdse-robots
| Tag used by FDSE search software, allows different robots instructions to be sent to FDSE than that sent to other search engines eg: index no index pages for local search
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| gcterms.topicTaxonomy
| Organize resources specifically for taxonomy-based topical browse or search structures on websites (ie: breadcrumbs / website information architecture).
| [http://www.gcpedia.gc.ca/wiki/Metadata_Tools#Metadata_for_Web_Resource_Discovery] Government of Canada, Web Content Management System Metadata Application Profile.
|
| Proposal

|-valign="top"
|icas.datetime.long
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of ICAS long date format such as "UCN 12012 M03 Blue ❀ day 333 ❀ IDC zone(UT) t969 tt189". example <meta name="icas.datetime.long" content="UCN 12012 M03 Blue ❀ day 333 ❀ IDC zone(UT) t969 tt189"/>
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
|icas.datetime.day
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of ICAS day-of-year format such as "2012 day 333 t969".
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
|icas.datetime.abbr
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of an ICAS abbreviated format such as "d2M03 t969".
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
|icas.datetime
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of an ICAS date and time format of unspecified information density (may include full, long, medium, short, or compressed forms).
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
| publisher
| Searching for one content publisher's or page publisher's work requires a standard robot-parsable format for the information. This often differs from creator or author when the publisher is an institution. An institutional name, personal name, or other text entry is permissible.<br />One element represents only one publisher. Multiple publishers are to be represented with multiple tags, although multiple publishers are less common than multiple authors or creators; multiplicity is more likely for a legal name and a well-known name.<br />Search engines may index by any component of a name, so a publisher need only enter a name once in one order.
| defacto standard, used in nearly every website, e.g. [http://www.gaijin.at/olsmgen.php][http://developers.evrsoft.com/metagen.shtml][http://www.html-seminar.de/metatags.htm]
|
| Proposal

|-valign="top"
| review_date
| The date a resource is scheduled for review by content creator in order to determine if it should be archived, updated or retained as is.
| [http://www.hc-sc.gc.ca/home-accueil/alt_formats/pacrb-dgapcr/pdf/Metadata_Application_Profile_2009.pdf Health Canada Web Metadata Application Profile March 2009 ]
|
| Proposal

|-valign="top"
| e-mailit-site-verification
| Used to verify ownership for E-MAILiT share buttons.
| [http://www.e-mailit.com/ E-MAILiT share buttons]
|
| Proposal

|-valign="top"
| es.title
| Object Title, where this is not the TITLE or H1 tag content, but the resource title
| [http://www.eibs.co.uk/reference/ EIBS EasySite CMS - Content Attributes Reference]
| dcterms.title
| Proposal

|-valign="top"
| format-detection
| Enables or disables automatic detection of possible phone numbers in a webpage in Safari on iOS.
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]
|
| Proposal

|-valign="top"
| fragment
| Opts a webpage into the AJAX crawling scheme when it does not have a "#!" URL. The only valid content value is "!".
<meta name="fragment" content="!">
| [https://developers.google.com/webmasters/ajax-crawling/docs/specification Google Crawable AJAX Specification]
|
| Proposal

|-valign="top"
| geo.position
| Geographic position to which the page is related.
<meta name="geo.position" content="48.02682000000001;7.809769999999958">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]
| icbm (different value syntax)
| Proposal

|-valign="top"
| geo.country
| Case-insensitive ISO 3166-1 alpha-2 code of a country to which the page is related.
<meta name="geo.country" content="de">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>[http://en.wikipedia.org/wiki/ISO_3166-2 ISO-3166-2]
|
| Proposal

|-valign="top"
| geo.a1
| National subdivision (state, canton, region, province, prefecture) of civil address to which the page is related. For resources within the US and Canada, corresponds to the common 2-character State/Province codes.
<meta name="geo.a1" content="AB">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776
|
| Proposal
|-valign="top"
| geo.a2
| County, parish, gun (JP), district (IN) of civil address to which the page is related.
<meta name="geo.a2" content="Warwickshire">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776
|
| Proposal
|-valign="top"
| geo.a3
| City, township, shi (JP) of civil address to which the page is related.
<meta name="geo.a3" content="Calgary">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776
|
| Proposal

|-valign="top"
| geo.lmk
| A landmark or vanity address to which the page is related.
<meta name="geo.lmk" content="Auwaldstraße 11, 79110 Freiburg im Breisgau, Deutschland">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]
|
| Proposal

|-valign="top"
| geo.region
| Superseded by either geo.country alone or geo.country plus geo.a1. Name of geographic region to which the page is related. Content is specified by ISO-3166.
<meta name="geo.region" content="DE-BW">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>[http://en.wikipedia.org/wiki/ISO_3166 ISO-3166]
|
| Proposal

|-valign="top"
| geo.placename
| Superseded by geo.lmk. Name of geographic place to which the page is related.
<meta name="geo.placename" content="London, Ontario">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]
|
| Proposal

|-valign="top"
| go-import
| Defines a remote source code location and version control scheme for the Go programming language's toolchain. Content format: <code>import-prefix vcs repo-root</code>.
| [http://golang.org/cmd/go/#hdr-Remote_import_path_syntax go tool documentation]
|
| Proposal

|-valign="top"
| google-site-verification
| Used to verify ownership for Webmaster Tools.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=79812 Google documentation]
|
| Proposal

|-valign="top"
| google-translate-customization
| Used to verify ownership for Website Translator.
| [http://googlewebmastercentral.blogspot.co.nz/2012_05_01_archive.html Google documentation]
|
| Proposal

|-valign="top"
| verify-v1
| Superseded by google-site-verification. Legacy verification for Google Sitemaps.
| [http://sitemaps.blogspot.com/2006/05/more-about-meta-tag-verification.html Inside Google Sitemaps: More about meta tag verification]
|
| Proposal

|-valign="top"
| google
| A content of "notranslate" will tell google not to pop up the translate bar / link if the page is in a foreign language form the user's browser.
<meta name="google" content="notranslate">
| [http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html Google blog post]
|
| Proposal

|-valign="top"
| googlebot
| Synonym of <code>robots</code> for targeting Googlebot only.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=93710 Google documentation]
|
|Proposal

|-valign="top"
| googlebot-mobile
| Synonym of <code>robots</code> for targeting Googlebot-Mobile
| [https://developers.google.com/webmasters/smartphone-sites/googlebot-mobile]
|
| Proposal

|-valign="top"
| revisit-after
| revisit-after is used to tell search engines how often to recrawl the page. To our knowledge only one search engine has ever supported it, and that search engine was never widely used — at this point, it is nothing more than a good luck charm.
| [http://code.google.com/webstats/2005-12/metadata.html Google documentation]
|
| Proposal

|-valign="top"
| icbm
| Defines geographic position to which page is related to. The acronym stands for ICBM Intercontinental Ballistic Missile - an old, humorous allusion to the possible use of such coordinates.<br>Example:
<meta name="ICBM" content="47.0667, 15.4500" />
| [http://geourl.org/add.html GeoURL documentation]
| geo.position (different value syntax)
| Proposal

|-valign="top"
| HandheldFriendly
| Denotes handheld-friendly content
| [http://learnthemobileweb.com/tag/handheldfriendly/]
|
| Proposal

|-valign="top"
| markosweb.com/validation
| Used to verify ownership of Markosweb.com
| [http://www.markosweb.com/help/ownership/ Markosweb Validation Help]
|
| Proposal

|-valign="top"
| mobile-web-app-capable
| Sets whether a web application can be added standalone to a home screen and launched in fullscreen mode. Also proposed as a vendor-neutral version of apple-mobile-web-app-capable.
| [https://developers.google.com/chrome/mobile/docs/installtohomescreen Add to Homescreen - Google Chrome Mobile — Google Developers] (though a WHATWG or W3C spec would be preferred)
| apple-mobile-web-app-capable (vendor specific synonym)
| Proposal

|-valign="top"
| StartVer
| Used to verify Websites for Start!-App
| No specification yet
|
| Proposal

|-valign="top"
| MobileOptimized
| Denotes content optimized for mobile browsers
| [http://learnthemobileweb.com/tag/mobileoptimized/]
|
| Proposal

|-valign="top"
| itemsPerPage
| Used to identify the number of search results returned per page.
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]
|
| Proposal

|-valign="top"
| msapplication-task
| '''"Jump List" or "Pinned Sites" in Windows 7'''
Jump List items act as entry points into the website even when the browser is not running. A Jump List can contain commonly used destinations and tasks. Some items apply to the whole site, and some apply only to specific users.
For example, to add a single task called "Check Order Status" specify a meta element in the head of your webpage, as follows:
<META name="msapplication-task" content="name=Check Order Status;
action-uri=./orderStatus.aspx?src=IE9;
icon-uri=./favicon.ico" />
| [http://msdn.microsoft.com/en-us/library/gg491725(v=vs.85).aspx Tasks in Jump List]
|
| Proposal

|-valign="top"
| msapplication-starturl
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-starturl" metadata contains the root URL of the application. The start URL can be fully qualified, or relative to the current document. Only HTTP and HTTPS protocols are allowed. If this element is missing, the address of the current page is used instead.
<meta name="msapplication-starturl" content="./" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-tooltip
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-tooltip" metadata provides additional tooltip text that appears when you hover over the Pinned Site shortcut in the Windows Start menu or on the desktop.
<meta name="msapplication-tooltip" content="Channel 9 Podcasts" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-tap-highlight
| '''Link highlighting in Internet Explorer'''
The "msapplication-tap-highlight" meta tag can be used to disable automatic highlighting of tapped links in Internet Explorer. Applies to IE10 on Windows Phone 8 and IE11 on Windows 8.1.
<meta name="msapplication-tap-highlight" content="no" />
| [http://msdn.microsoft.com/en-us/library/ie/bg182645%28v=vs.85%29.aspx#tapHighlight Link highlighting]
|
| Proposal

|-valign="top"
| msapplication-navbutton-color
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-navbutton-color" metadata define the custom color of the Back and Forward buttons in the Pinned Site browser window. Any named color, or hex color value is valid.
<meta name="msapplication-navbutton-color" content="#FF3300" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-window
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-window" metadata sets the initial size of the Pinned Site window when it is launched for the first time. However, if the user adjusts the size of the window, the Pinned Site retains the new dimensions when it is launched again.
The following properties can be used in the value of the <code>content</code> attribute:
* width - The window width in pixels. The minimum value is 800.
* height - The window height in pixels. The minimum value is 600.
<meta name="msapplication-window" content="width=1024;height=768" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-TileImage
| The "msapplication-TileImage" metadata define the path to an image to be used as background for a tile in Pinned Sites in Windows 8. Tile images must be square PNGs 144px by 144px.
<meta name="msapplication-TileImage" content="images/benthepcguy-144.png" />
| [http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx High Quality Visuals for Pinned Sites in Windows 8]
|
| Proposal

|-valign="top"
| msapplication-TileColor
| The "msapplication-TileColor" metadata define the background color of a tile in Pinned Sites in Windows 8. The tile color can be specified as a hex RGB color using CSS’s #rrggbb notation, via CSS color names, or by the CSS rgb() function.
<meta name="msapplication-TileColor" content="#d83434"/>
| [http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx High Quality Visuals for Pinned Sites in Windows 8]
|
| Proposal

|-valign="top"
| msapplication-square70x70logo
| '''msapplication-square70x70logo'''
Specifies the image to use as the small tile, which is 70x70 pixels at 100% scaling.
<meta name="msapplication-square70x70logo" content="images/tinylogo.png">
'''Note''' The '''msapplication-square70x70logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msapplication-square150x150logo
| '''msapplication-square150x150logo'''
Specifies the image to use as the wide tile, which is 310x150 pixels at 100% scaling.
<meta name="msapplication-square150x150logo" content="images/logo.png">
'''Note''' The '''msapplication-square150x150logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msapplication-wide310x150logo
| '''msapplication-wide310x150logo'''
Specifies the image to use as the medium tile, which is 150x150 pixels at 100% scaling.
<meta name="msapplication-wide310x150logo" content="images/widelogo.png">
'''Note''' The '''msapplication-wide310x150logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msapplication-square310x310logo
| '''msapplication-square310x310logo'''
Specifies the image to use as the large tile, which is 310x310 pixels at 100% scaling.
<meta name="msapplication-square310x310logo" content="images/largelogo.png">
'''Note''' The '''msapplication-square310x310logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msvalidate.01
| One of the verification elements used by Bing.
| [http://onlinehelp.microsoft.com/en-us/bing/hh204490.aspx Bing Webmaster Tools]
|
| Proposal

|-valign="top"
| og:audio
| A URL to an audio file to accompany this object.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:description
| A one to two sentence description of your object.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:determiner
| The word that appears before this object's title in a sentence. An enum of (a, an, the, "", auto). If auto is chosen, the consumer of your data should chose between "a" or "an". Default is "" (blank).
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:image
| An image URL which should represent your object within the graph.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:locale
| The locale these tags are marked up in. Of the format language_TERRITORY. Default is en_US.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:locale:alternate
| An array of other locales this page is available in.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:site_name
| If your object is part of a larger web site, the name which should be displayed for the overall site. e.g., "IMDb".
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:title
| The title of your object as it should appear within the graph, e.g., "The Rock".
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:type
| The type of your object, e.g., "video.movie". Depending on the type you specify, other properties may also be required.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:url
| The canonical URL of your object that will be used as its permanent ID in the graph, e.g., "http://www.imdb.com/title/tt0117500/".
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:video
| A URL to a video file that complements this object.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| norton-safeweb-site-verification
| Used to verify ownership of Website for Norton SafeWeb.
| [http://safeweb.norton.com/help/site_owners#verification_tips Norton SafeWeb Help Documentation]
|
| Proposal

|-valign="top"
| pinterest
| Used to block pinterest from linking to content on the URL.
Example:
<code><meta name="pinterest" content="nopin"/></code>
| [https://support.pinterest.com/entries/21101932-what-if-i-don-t-want-images-from-my-site-to-be-pinned Pinterest Help Article]
|
| Proposal

|-valign="top"
| rating
| The Restricted to Adults label (RTA) provides a way for adult oriented websites to indicate that their content is off limits to children. RTA was introduced in 2006 and is currently used by a large number of adult web content providers. RTA is recognized by all major parental control filters.
Example:
<meta name="RATING" content="RTA-5042-1996-1400-1577-RTA" />
| [http://www.rtalabel.org/index.php?content=howto RTA documentation]

|
| Proposal
|-valign="top"
| referrer
| Controls whether the user agent includes the Referer header in HTTP requests originating from this document
| [http://wiki.whatwg.org/wiki/Meta_referrer Meta referrer]
|
| Proposal

|-valign="top"
| RepostUsAPIKey
| Used to verify ownership of Website for Repost syndication service
| [http://www.repost.us/meta-headers-used-by-repost/ Meta Headers used by Repost]
|
| Proposal

|-valign="top"
| ResourceLoaderDynamicStyles
| [[mw:|MediaWiki]]'s [[mw:ResourceLoader|ResourceLoader]] uses this name with <code>content</code> set to the empty string. The purpose is to mark the DOM position before which dynamic styles should be added.
| [[mw:ResourceLoader/ResourceLoaderDynamicStyles specification|ResourceLoaderDynamicStyles]]
|
| Proposal
|-valign="top"
| rights-standard
| The purpose is to enable search engines and other cataloging services to compile the types of rights allocated to the work. (Does any search engine actually implement this? [[User:Hsivonen|hsivonen]] 07:34, 14 July 2011 (UTC))

'''This keyword does not provide, remove or alter any legal protections or designations.'''

Format:
<pre><meta name="rights-standard" content="element id;rights" /></pre>

* element id - the HTML Element ID of the item these rights apply to
* rights - what rights are assigned to the item
** "pd" - Public domain
** "cc by-sa" - Creative Commons Attribution
** "cc by-nd" - Creative Commons NoDerivs
** "cc by-nc" - Creative Commons Attribution-NonCommercial
** "cc by-nc-sa" - Creative Commons Attribution-NonCommercial-ShareAlike
** "cc by-nc-nd" - Creative Commons Attribution-NonCommercial-NoDerivs

| [http://sites.google.com/site/metarightsstandard/ Spec]
|Redundant with [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#licensing-works Microdata vocabulary for licensing works].
|Proposal

|-valign="top"
| robots
| A comma-separated list of operators explaining how search engine crawlers should treat the content. Possible values are "noarchive" to prevent cached versions, "noindex" to prevent indexing, and "nofollow" works as the link rel value with the same name. This meta name is already supported by every popular search engine.<br />The content value "NOODP" has been offered elsewhere, so I'm proposing it here. It blocks robots from using [http://www.dmoz.org Open Directory Project] descriptions of a website instead of Web pages' own meta descriptions. It may have been introduced by Microsoft.<br />The content value "NOYDIR" has been offered by Yahoo, so I'm proposing it here. It blocks Yahoo's robot from using the Yahoo directory's descriptions of a website instead of Web pages' own meta descriptions. Whether any other robot supports this is unknown but possibly no other search engine uses Yahoo's directory anyway.
| [http://www.robotstxt.org/wc/exclusion.html#meta Robots exclusion protocol], NOODP value: [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35264 Google], [http://help.yahoo.com/l/us/yahoo/search/indexing/indexing-11.html Yahoo], NOYDIR value: [http://ysearchblog.com/2007/02/28/yahoo-search-support-for-noydir-meta-tags-and-weather-update/ Yahoo], as accessed 4-28-09
|
| Proposal

|-valign="top"
| rpuPlugin
| Version of installed Repost syndication service plugin
| [http://www.repost.us/meta-headers-used-by-repost/ Meta Headers used by Repost]
|
| Proposal

|-valign="top"
| skype_toolbar
| Prevents the Skype browser extension from automatically seeking through the page and replacing telephone numbers (or any number the program's algorithm thinks is a telephone number) with its own custom presentation that allows direct invocation of the Skype program to call the telephone number.

Example:
<meta name="skype_toolbar" content="skype_toolbar_parser_compatible" />
| [http://skype.otherlinks.co.uk/page.asp?id=toolbar_number_formatting Skype Info]
|
| Proposal

|-valign="top"
| slurp
| Synonym of <code>robots</code> for targeting Yahoo! only.
| [http://help.yahoo.com/l/au/yahoo7/search/indexing/indexing-11.html Yahoo! documentation]
|
| Proposal

|-valign="top"
| startIndex
| Used to identify the index of the first search result in the current set of search results.
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]
|
| Proposal

|-valign="top"
| teoma
| Synonym of <code>robots</code> for targeting Teoma and Ask.com only.
| [http://about.ask.com/en/docs/about/webmasters.shtml Ask.com documentation]
|
| Proposal

|-valign="top"
| totalResults
| Used to identify the number of search results available for the current search.
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]
|
| Proposal

|-valign="top"
| <span id="viewport">viewport</span>
| Provides a way for documents to specify (using markup rather than CSS) the size, zoom factor, and orientation of the viewport that is used as the base for the document's [http://www.w3.org/TR/CSS21/visudet.html#containing-block-details initial containing block]. The following properties can be used in the value of the <code>content</code> attribute:
* width
* height
* initial-scale
* minimum-scale
* maximum-scale
* user-scalable
Examples:
<meta name="viewport" content="initial-scale=1.0">
<meta name="viewport" content="width=480, initial-scale=2.0, user-scalable=1">
For more details, see the [http://dev.w3.org/csswg/css-device-adapt/#viewport-meta-element Viewport META element] section of the [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] draft specification.
| For <code>meta</code> elements that have a <code>name</code> attribute whose value is <code>viewport</code>, the [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] draft specification defines the recognized properties for the <code>content</code> attribute>, as well as an algorithm for parsing the value of that attribute.
|
| Proposal

|-valign="top"
| wt.cg_n
| '''Name of the Content Group'''
Used to configure the appropriate Webtrends advanced feature. These are just some of the more popular ones. These appear in your META tags. – showing you the web page, the source (meta tag), the log files entry and the subsequent WT report.
Example:
<meta name="wt.cg_n" content="My content">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.cg_s
| '''Name of Content Sub-Group'''
Used to configure the appropriate Webtrends advanced feature. These are just some of the more popular ones. These appear in your META tags. – showing you the web page, the source (meta tag), the log files entry and the subsequent WT report.
Example:
<meta name="wt.cg_s" content="My content">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| WT.si_n
| '''Scenario analysis parameter - scenario name'''
This defines a scenario name for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends.
Example:
<meta name="WT.si_n" content="my_scenario_name">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].
|
| Proposal

|-valign="top"
| WT.si_p
| '''Scenario analysis parameter - scenario step name'''
This defines a scenario step name for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends. It works when paired with metedata tag name WT.si_n.
Example:
<meta name="WT.si_p" content="my_scenario_step_name">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].
|
| Proposal

|-valign="top"
| WT.si_x
| '''Scenario analysis parameter - scenario step number'''
This defines a scenario step number for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends. It works when paired with metedata tag name WT.si_n, and as an alternative to Wt.si_p.
Example:
<meta name="WT.si_x" content="my_scenario_step_number">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].
|
| Proposal

|-valign="top"
| wt.ac
| '''Advertising Click parameter'''
When a visitor to your site clicks on an ad, that action is referred to as an Ad Click. The following META tag tracks advertising clicks:
<META NAME="WT.ac" CONTENT="name">
Defines the name of the advertisement clicked to reach a particular web page. The Ad Click must contain an external redirect back to the client. The redirect needs to include the necessary code to generate a hit to the SDC server. You can designate multiple Advertising Clicks using semicolons.
Examples:
<a href="file111.html?WT.ac=CONTENT111">
<a href="file222.html?WT.ac=CONTENT222">
The name of the advertisement clicked to reach a particular web page. To capture this information with DCS, the Advertising Click must contain an external redirect back to the client. The redirect needs to

include the necessary code to generate a hit to the DCS. The maximum length for each name is 64 bytes.
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.ad
| '''Advertising View parameter'''
Visitors often view advertisements that they do not necessarily click on. You can use On-Site Advertising to determine the number of visitors to your web site who view particular ads. With this feature you can produce advertising reports for each of your clients.
If you are selling advertising space on your web site, for example, you can collect traffic statistics to help determine pricing schedules.
The following META tag tracks advertising views:
<meta name="WT.ad" content="My content">
An Ad View occurs when a visitor views a page containing an ad. An ad is a link or graphic that contains an Ad Click parameter in the query portion of it's URL.
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.mc_id
| '''Identifies the ID of the marketing campaign'''
To attract new students, a university launches a marketing campaign by sending recruitment email to all graduating high school seniors in a metropolitan area. The email links to a special landing page in the university’s web site, containing the following META tag to track marketing campaigns.
Example:
<META NAME="WT.mc_id" CONTENT="1X2GG34">
You may use this parameter on the URL.
Example:
<a href="link?WT.mc_id=1X2GG34">
The Campaign ID 1X2GG34 represents recruits to be contacted by email
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.sv
| '''Tracking Servers parameter'''
If your site is hosted on multiple servers, a server cluster, or a server farm, and you want to evaluate the performance of your load balancer, Webtrends can track page views for each server. To do so, populate the following META tag on all pages on each server:
Example:
<meta name="WT.sv" content="My Server">
Defines the name of the machine that serves the web page. If you have two servers (Server1 and Server2), you would make two copies of the META tag and designate CONTENT=“Server1” for deployment to pages on the first server and CONTENT=“Server2” for deployment to the same pages on the second server.
For a server farm, you can extract the value of the built-in server name and dynamically assign it to the
META tag using server-side scripting.
Example:
<meta name="WT.sv" content="Server1">
<meta name="WT.sv" content="Server2">
An Ad View occurs when a visitor views a page containing an ad. An ad is a link or graphic that contains an Ad Click parameter in the query portion of it's URL.
| [https://tagbuilder.webtrends.com/Help/Miscellaneous/AdSearch.aspx?keepThis=true&TB_iframe=true&height=450&width=650 About WT.ad].
|
| Proposal

|-valign="top"
| wt.ti
| '''Tracking Page Titles'''
You may want to modify a page title before sending it to Webtrends in the following cases:
* You are dealing with dynamic content pages identified by URL parameters, and the page title represents the title of the base URL page rather than the dynamic content page.
Unless you modify the page titles, all pages have the same title in the reports.
* All pages have been assigned the same title, for reasons of style or company policy.
Even though URLs are displayed in addition to page title, the entire URL cannot be depended upon to distinguish one page from another.
Use server-side scripts to change the title to something that reflects the content of the pages so that you can identify them in reports. Next, pass the customized page titles to Webtrends, using the following META tag:
<META NAME="WT.ti" CONTENT="title">
Defines the name of the title for this page.
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| y_key
| Used to verify ownership for Yahoo! Site Explorer
| [http://help.yahoo.com/l/us/yahoo/search/siteexplorer/siteexplorer-06.html Yahoo! documentation]
|
| Proposal

|-valign="top"
| yandex-verification
| Used to verify ownership for Yandex Webmaster.
| [http://help.yandex.ru/webmaster/?id=995300#995356 Yandex Webmaster ownership verification]
|
| Proposal

|-valign="top"
| globrix.instruction
| Globrix property information: Property to Buy or Rent
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.price
| Globrix property information: Price for the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.postcode
| Globrix property information: Postcode of the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.bedrooms
| Globrix property information: Number of bedrooms the property has
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.bathrooms
| Globrix property information: Number of bathrooms the property has
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.type
| Globrix property information: Type of property e.g. 'semi-detatched house'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.condition
| Globrix property information: Condition of the property e.g. 'renovated'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.features
| Globrix property information: Features of the property e.g. 'double glazing'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.outsidespace
| Globrix property information: External features of the property e.g. 'garden'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.parking
| Globrix property information: Parking available for property e.g. 'parking for 2 cars'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.period
| Globrix property information: Period of the property e.g. 'victorian terrace'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.poa
| Globrix property information: If the property price is only available on application
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.tenure
| Globrix property information: The tenure of the property e.g. 'leasehold'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.underoffer
| Globrix property information: Indicates if the property is under offer
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.priceproximity
| Globrix property information: The region of the attached price e.g. 'guide price of'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.latitude
| Globrix property information: The latitude of the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.longitude
| Globrix property information: The longitude of the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| meta_date
| The date used to indicate that the Metadata has been prepared and/or reviewed and approved by the Metadata Unit. Its purpose is administrative. (Used by "Autonomy".)
| [http://www.hc-sc.gc.ca/home-accueil/alt_formats/pacrb-dgapcr/pdf/Metadata_Application_Profile_2009.pdf Health Canada Web Metadata Application Profile March 2009 ]
|
| Proposal

|-valign="top"
| Site-Type
| Used to define the body of the document content type offered
| [http://programadorweb.net.tc/?page_id=124 Information and values ??accepted by Metatag]
|
| Proposal

|-valign="top"
| wot-verification
| Used to verify ownership of WOT (Web Of Trust)
| [http://www.mywot.com/wiki/Verify_your_website WOT's verify your site wiki page]
|
| Proposal

|-valign="top"
| gwt:property
| Used to specify the locale client property
| [https://developers.google.com/web-toolkit/doc/latest/DevGuideI18nLocale Locales in GWT]
|
| Proposal

|-valign="top"
| mobile-agent
| Specifies the mobile-compatible url of the web page. Used by mobile browsers and search engines to redirect mobile phone visitors to the proper mobile page. <br>
The following properties can be used in the value of the content attribute:<br>url - The mobile-compatible url of the web page.<br>format - The format of the mobile page. An enum of "wml", "xhtml" and "html5".<br>Example:
<meta name="mobile-agent" content="format=html5; url=http://3g.sina.com.cn/">
| [http://open.shouji.baidu.com/?page=developer&action=pcandmo Baidu Mobile SEO]
|
| Proposal

|-valign="top"
| twitter:card
| The card type, which will be one of "summary", "photo", or "player".
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:domain
| the domain of the website (added w/ API 1.1)
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:url
| Canonical URL of the card content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:title
| The title of the content as it should appear in the card.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:description
| A description of the content in a maximum of 200 characters.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image
| A URL to the image representing the content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image:width
| The width of the image representing the content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image:height
| The height of the image representing the content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image0
| A URL to the image representing the first photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image1
| A URL to the image representing the second photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image2
| A URL to the image representing the third photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image3
| A URL to the image representing the fourth photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:site
| @username for the website used in the card footer.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:site:id
| Twitter ID for the website used in the card footer.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:creator
| @username for the content creator / author.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:creator:id
| Twitter ID for the content creator / author.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| typemetal.formatprefs
| Per-file HTML formatting preferences used by the TypeMetal HTML editor
| [http://coherencelabs.com/typemetal/manual/typemetal-custom-metadata.html TypeMetal User Guide]
|
| Proposal

|-valign="top"
| vfb-version
| Specifies a Visual Form Builder plugin version for Wordpress.
| [http://wordpress.org/plugins/visual-form-builder/ Visual Form Builder Documentation and specs]
|
| Proposal

|-valign="top"
| wot-verification
| Used to verify ownership of WOT (My Web of Trust).
| [http://www.mywot.com/en/faq/site-owners-support/ownership-verification#why-verify]
|
| Proposal

|-valign="top"
| web_author
| Credits the developer(s) responsible for the technical design of a website.
| [http://www.metatags.info/meta_name_webauthor Documentation]
| [https://sites.google.com/site/metadesignerspec/ designer] - for visual presentation
| Proposal

|-valign="top"
| ZOOMCATEGORY
| Category of page to be grouped in Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMDESCRIPTION
| Alternative page description for Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMIMAGE
| URL to image to be displayed alongside result in Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMPAGEBOOST
| Page boost factor to increase or decrease the relevance of page in Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMTITLE
| Alternative page title for Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMWORDS
| Additional keywords to be indexed for Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| revision
| The revision of this page as reported by an underlying Version Control System. This is a free format string.
| [https://github.com/krallin/meta-revision Meta Revision Specification]
|
| Proposal
|}

== Proposals that don't meet the [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names requirements] for a registration ==

Note that these proposals can be moved back to the registry table if the problems listed in the rightmost column of this table are addressed.

{| class="wikitable sortable"
! Keyword
! Brief description
! Link to specification
! Synonyms
! Status
! Registration requirement failure

|-valign="top"
| gm-gpx-v
| Wordpress Plugin Google Maps GPX Viewer
| [http://wordpress.org/extend/plugins/google-maps-gpx-viewer/ Google Maps GPX Viewer]
|
| Incomplete proposal
| Claimed spec link is not a link to a spec

|-valign="top"
| og:title
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:type
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:url
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:image
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:site_name
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| fb:admins
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:description
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| fb:page_id
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| audience
| To aid search engines in classifying and to aid directory compilers, an audience most appropriate for the page may be suggested. Subject matter may not be a good clue; for example, an analysis of children's literature may be directed to teachers.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated. Singular and plural forms have the same meaning.<br />Recognized values:<br />-- "all" and "everyone", which have the same meaning<br />-- "adult" and "mature" have the same meaning and are for content that only adults may access, but no one responsible for preventing a nonadult or the immature from accessing the page or its content should rely on either or both of these values to do so without other means (not the same as "grownup", which see)<br />-- "child" and "juvenile", which have the same meaning<br />-- "teen"<br />-- "grownup" is not identical to "adult" or "mature" in not implying a precise boundary but is approximately any person who may be able to understand and apply the content (e.g., car driving instruction that may be read by a minor not yet old enough to drive a car but who would likely benefit from somewhat early exposure to the instruction)<br />-- "parent" to include guardian and temporary caregiver<br />-- "teacher" to include professor and ad hoc instructor<br />-- "elementary school student" to include any student below high school<br />-- "high school student"<br />-- "elhi" to include any student in elementary school through high school<br />-- "college student" including graduate and professional school<br />-- "business" including management, finance, and prospective customers (this includes e-commerce and investor sites)<br />-- "health" including any health care provider including alternative and ad hoc<br />-- "patient" for any health care recipient<br />-- "lawyer" including judge, paralegal, and jailhouse lawyer<br />-- "law client" for any prospective recipient of a lawyer's service (not usually a social work client) with ''lawyer'' including paralegal and jailhouse lawyer but not necessarily judge<br />-- "craft" for any craftworker including laborer and artisan<br />-- "artist" including musician, actor, dancer, and sculptor and including creator and performer<br />-- "military" including paramilitary<br />-- "news" including any consumer of rapidly-developing news<br />-- "introductory" and "beginner", which have the same meaning<br />-- "intermediate" and "midlevel", which have the same meaning<br />-- "advanced" and "advance", which have the same meaning<br />-- "scholarly" and "scholar", which have the same meaning<br />-- "popular" generally referring to a writing style<br />-- "older" including retiree<br />-- "institution" including from corporation to conspiracy (such as for management advice)<br />-- "government" including agencies and prospective politicians<br />-- values using any integer or single-digit decimal in the form of "grade 8" or "grade 6.4" including to refer to a reading comprehension level (this generally will not exceed 12 and might be meaningless above 20 so higher values may be interpreted as the highest meaningful value)<br />-- "viewers" for when content (such as a movie) is intended almost entirely to be seen rather than read<br />-- "listeners" for when content (such as music) is intended almost entirely to be heard rather than read but not generally including text-to-speech support<br />-- "tts", "text-to-speech", or "text to speech", which three have the same meaning and which are for a page that has substantial support for TTS or that will be readily understood through TTS without need for such support (TTS is often aided by, e.g., pre-resolving pronunciation ambiguities in page coding)<br />-- values using any numbers in the form of "3-6 years old", whether a range or a single-number value<br />-- values using any decade in the form of "born in 1970s"<br />Unrecognized values such as "botanists", "Texans", and "writers who use red ink" may be used but at a risk that a search engine or directory editor will either fail to recognize it or will interpret it in unpredictable ways, or will in the future.<br />Spellings that are erroneous or slightly different from a recognized value may be interpreted by a search engine or directory editor as representing a recognized value.<br />The absence of the keyword defaults to a value of "all" but without overriding another indication arrived at by other means.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| blogcatalog
| Used to verify ownership of Blog Catalog.com
| [http://www.blogcatalog.com/ Blog catalog site]
|
| Incomplete proposal
| Claimed spec link is not a link to a spec

|-valign="top"
| bot-. . .
| Robot owners, to allow page authors access to robotic capabilities, e.g., to deny them, should prefix "bot-" to the name of their robot, especially for proprietary bots.<br />Example: If a robot were to be named "dullbucklequiz", the name in the meta element would be "bot-dullbucklequiz".<br />The value "bot-" alone represents all bots so prefixed, like a wildcard.<br />Arguably, there's no need for a list here of any specific bots if http://user-agents.org or http://www.botsvsbrowsers.com/ (and perhaps other sites) is reliable.
|
|
| Incomplete proposal
| Lacks link to a spec, tries to register a space of names instead of enumerated names

|-valign="top"
| created
| The datetime at which the document was created. The value is an ISO8601 date. The date MUST follow the [http://www.w3.org/TR/NOTE-datetime W3C Profile of ISO 8601] with a granularity of "Complete date:" or finer. The [http://www.bbc.co.uk/guidelines/futuremedia/desed/previousversions/searchmetadata_vs_1_0.shtml#metadata BBC] use this name.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| creator
| The creator is an off-Web or pre-Web creator of a work for which an author authored a Web page, so that the creator and the author may be different people.<br />Searching for one content creator's work requires a standard robot-parsable format for the information. A personal name, institutional name, or other text entry is permissible.<br />One element represents only one creator. Multiple creators are to be represented with multiple tags.<br />Search engines may index by any component of a name, so a content creator need only enter a name once in one first-last or family-given order (e.g., Pat Thunderbird or Thunderbird, Pat, but not requiring both).
| [[Talk:MetaExtensions#Re:_Proposed_'creator'_MetaExtension|Talk]]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| msnbot
| Synonym of <code>robots</code> for targeting Bing only.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| ia_archive
| Synonym of <code>robots</code> for targeting Internet Archive and Alexa only.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| datetime-coverage
| The author may be the best expert on which time frame is most relevant to the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers that may focus on the 1800s but mention 1731 and 1912 perhaps unimportantly.<br />The value for this keyword is a date or time -- not a range and not vague, for which other keywords are proposed -- in a format in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, all the values so appearing are determinative. Multiple values are to be expressed with separate meta elements lest the note be revised in the future in a way incompatible with comma-separating a list.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| property="og:*"
| Metadata used by the Open Graph protocol (used by Facebook). Note: currently these are defined as: <meta property="og.*" content="x"/>
| [http://developers.facebook.com/docs/opengraph/ FAQ About the Open Graph protocol from Facebook.]
|
| Doesn't belong in this registry
| Not a value to be used in the <code>name</code> attribute

|-valign="top"
| datetime-coverage-end
| This is identical to the keyword datetime-coverage except that it represents only the end. If this keyword is used without datetime-coverage-start (also proposed), its value is interpreted as ending a range without a start.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the end of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-end=1865, datetime-coverage-start=1914, datetime-coverage-end=1918, and datetime-coverage-start=1862, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| datetime-coverage-start
| This is identical to the keyword datetime-coverage except that it represents only the start. If this keyword is used without datetime-coverage-end (also proposed), its value is interpreted as starting a range without an end.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the start of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-start=1862, datetime-coverage-start=1914, datetime-coverage-end=1865, and datetime-coverage-end=1918, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| datetime-coverage-vague
| This is identical to the keyword datetime-coverage except that its value is not necessarily crisp. This keyword should be used only when datetime-coverage, datetime-coverage-start, and datetime-coverage-end are inappropriate, but there's no ban on using all four. Any text without a comma can be the value (e.g., Pleistocene, 1820s, Tuesdays, or before we were born); multiple values are comma-separated.<br />If this keyword is used with datetime-coverage, datetime-coverage-start, or datetime-coverage-end, the vague value should be exploited along with the value/s for the other keyword/s.<br />Should this keyword appear more than once, all are determinative.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| DC.
| Dublin Core, maintained by Dublin Core MetaData Initiative (DCMI), is an extensive system with some overlap with non-DC names.<br />This reserves all strings that begin with DC and a dot. ''Not true; DC-HTML doesn't use hardwired prefixes, but defines the prefixes using link/@rel="scheme.prefix"''
| [http://www.DublinCore.org DCMI]
|
| Incomplete proposal
| Tries to register a space of names instead of enumerated names

|-valign="top"
| dir-content-pointer
| When several pages in a directory include main content, a table of contents, an index, and the like, a search engine may be able to organize results more usefully by identifying which is which with a standard vocabulary, helpful when different publishers use different conventions when displaying or printing content.<br />A value is free-form case-insensitive text without a comma and optionally with a trailing number. Multiple values are to be comma-separated (multiple values are appropriate when one document serves multiple purposes). Singular and plural forms have the same meaning.<br />Recognized values, which are pointer types to which numbers may be suffixed, are limited to "start" meaning 'the first page that should be seen by a user' (this may be anywhere in the directory and anywhere within content), "toc" meaning 'table of contents', "intro" including introductions, forewords, prefaces, and tables of figures, "abstract", "main", "bibliography" and "biblio", which have the same meaning, "index" which may mean 'sitemap' or not, "afterword" and "update" which have the same meaning and need not actually update, "credit" meaning 'credits and acknowledgments', and "author bio" meaning 'author's biography', including any information about the author including credentials and contact information. The number suffix may be spaceless or not.<br />When numbers are suffixed, a search engine or directory should arrange like items in numerical order in the results, with unnumbered items following like items that are numbered, e.g., intro 1, intro 2, main 1, main 2, main, main, and so on.<br />Each directory and each subdirectory has its own sequence.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
|expires
|<code>meta name='expires'</code> defines the expiration date of the page. This can be used for web pages in preparation for an upcoming event, e.g. a registration form for an exposition or competition, or other cases with a pre-set date when the document will no longer be valid, e.g. a product offer in a special sale or a support page for a product known not to be supported anymore from a given time onward.

Search engines should respond to this meta tag in a reasonable way, i.e. by removing the page from their main search results after the expiration date (possibly still returning the result in a special search for expired pages as long as the page exists and is not explicitly excluded via <code>robots.txt</code> or <code>meta name='robots'</code> etc.) or simply by indicating to the user that this result is out-of-date.

The content attribute should define the expiration date in accordance with http://www.w3.org/TR/NOTE-datetime . The meta tag should not be used for pages without expiration date. However, for historical reasons, search engines should also interpret other date formats where possible and should be prepared to find values such as "", "0", "no" and "never". Such non-date values are to be interpreted as no expiration date.

Correctly formatted example:
<code><pre><meta name='expires' content='2012-12-31T23:59Z'></pre></code>

This tag is not to be confused with and has a different meaning than <code>meta http-equiv='expires'.</code>
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| format-print
| This is to allow a user agent to inform an operating system or a printer driver of the preferred print medium, such as the paper size.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated (multiple values might be appropriate because standard paper sizes vary around the world). Singular and plural forms have the same meaning.<br />Recognized values are limited to "letter", "A4", "legal", "A5", "B5", "monarch", "envelope 10" meaning size #10, "envelope 6-3-4" meaning size #6 3/4, values with integers and decimals in the form of "8.5 x 11" or "8.5x11" in which spacing of the "x" does not affect meaning, "paper", which means 'paper of the default color (usually white) and weight (usually 20-lb. stock)', "white", "yellow", "pink", "blue", "green", "violet", or "multicolor", which means a medium of the given color or mixed, "letterhead", "p2 letterhead" meaning 'letterhead intended for any page except the first', "watermark" meaning a 'special watermark such as an organization's own', and "plain" meaning 'not preprinted and not letterhead (it may have a paper manufacturer's watermark not related to letterhead)'.<br />Omitting "paper" when another recognized value is given defaults to an implied meaning of 'paper' with the other value; e.g., "letter" means 'letter paper'; the same principle applies to a medium's color (the default being white for paper and colorless for transparency) and plainness or lack thereof (the default being plain).<br />Other values should be proposed before being recognized here. Label sizes should be proposed here for labels that are not on backing sheets that fit one of the recognized values, e.g., labels on narrow rolls. Blueprint paper sizes should be proposed here. Media other than standard paper, such as onion skin, heavier paper, card, and clear or color transparency, should be proposed here.<br />The user agent may, with the user's or user sysadmin's permission (as by a menu-driven default), interpret a value to offer an alternative the user might accept and software and firmware other than the UA may interpret a value to the same end with or without permission, so this keyword is only suggestive; e.g., "letter" may be interpreted as "A4".<br />The absence of the keyword defaults to a value determined by other than the page, e.g., by the printer driver or the user agent.
| [[Talk:MetaExtensions#Re:_Proposed_'format-print'_MetaExtension|Talk]]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| geographic-coverage
| The author may be the best expert on the geographic relevance of the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers and epidemiological studies which may mention locales only once.<br />Absence of the keyword defaults to a value of world (not universe), unless the search engine chooses to interpret the page or larger unit for some other value, probably based on other than just contact information given in the website.<br />The value for this keyword is a semicolon-separated list of one or more place-values, the order of which do not matter. One place-value will use commas to separate, in order, an optional standard natural language symbol applicable to the place-value (when omitted the language applicable to the page will control), a place-class, one or more place-subclasses if any, and one or more place name parts (where, e.g., in "Cape Town, South Africa", "Cape Town" is a place name part but "Town" is not). Spaces after semicolons and commas are optional; spaces within place-values are present when required for each place-value (e.g., "Quezon City", not an invented "QuezonCity").<br />To distinguish names that might otherwise be too similar, place-classes, all lower-case and hyphenatably spaceless, include ''outer-space'', ''region'' (on Earth and crossing or larger than a nation, e.g., southern hemisphere, polar region, temperate zone, or Asia), ''intntl-water'' (an 'international water body'), ''intntl-agcy'' ('international agency' or 'international collection', e.g., all U.N. member nations), ''nation'', ''within-nation'' (limited to only one political level down from nation, e.g., state, province, territory, possession, city not included within other political units of a nation, or any comparable unit), ''city'' (including town, village, hamlet, and any comparable political unit below the level of ''within-nation''), ''addr'' (including address, full-length street, building, institution, and neighborhood without political boundaries), ''pol-unit'' (''pol'' abbreviating 'political') (e.g., a place of disputed nationhood), ''hist-pol-unit'' (''hist'' abbreviating 'historical') (e.g., the Roman Empire), ''feature'' (e.g., river), ''num'' (e.g., latitude and longitude or outer-space equivalent in numbers), and ''ethereal'' (including thealogical/theological, fictional including from modern popular entertainment, and ancient secular mythical, but not including that which is asserted to be a state of mind or existence but not a place, such as nirvana). (Example for one hypothetical page: name="geographic-coverage" content="region, sub-Saharan Africa; nation, Panama; city, Panama, Panama; within-nation, Sao Paulo, Brazil; city, Sao Paulo, Sao Paulo, Brazil; within-nation, Mississippi, United States of America; region, Middle East; region, Midwest, United States of America; hist-pol-unit, Northwest Territory, United States of America; feature, river, Indus; outer-space, Indus; ethereal, ultima Thule; ethereal, Heaven; ethereal, Flatland; ethereal, Valhalla; en-US, addr, Hotel Valhalla, Fredrikstad, Norway; es, nation, Espana" (Indus is both a river and a constellation, illustrating the need for place-classes)).<br />Ambiguity of place-values should be avoided despite convenience in coding because search engines may each interpret them as they see fit, e.g., it would be hard for an engine to distinguish New York from New York.<br />For consistency of spelling, several authority lists should be settled upon, with legal, well-known, and disputed names and common abbreviations all being acceptable; but I'm not proposing one here now (relying on IANA's ccTLD list might be too complex to implement and still assure coding consistency, e.g., occasionally ccTLDs can be phased out and off of IANA's list) (a standard vocabulary possibly usable here is the [http://www.getty.edu/research/conducting_research/vocabularies/tgn/index.html Getty Thesaurus of Geographic Names Online], subject to licensing and charset choice); and promulgating authority lists may best be done publicly by search engine managements, who may disagree with each other.<br />Allowing Unicode for non-Roman alphabet-using locales is desirable, but at present that may raise technical problems, including computer security issues, that are not yet readily soluble.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| keywords-not
| A comma-separated list of negative keywords that distinguish a closely-related theme from this page's true theme, to support Boolean NOT searches often more realistically than visible text can, especially when both themes share the same lexicon.<br />If keywords is no longer a supported name for a meta element, keywords-not is superfluous; however, debate has been revived on whether keywords should be supported or not; see the keywords entry in this Wiki.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6609 W3C Bug 6609]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| nextgen
| Used for nextgen gallery plugin in wordpress
| [http://www.alexa.com/faqs/?p=188 Alexa FAQ About this meta attribute Reference]
|
| Incomplete proposal
| Unrelated spec link

|-valign="top"
| page-datetime
| Better ranking in search engine results for recency or relevance to an event date would be aided by a standard format robots can parse. Users would save search time by not having to load many pages to find which ones are new or date-relevant.<br />To supply a consistent and known format, the value for this keyword is a date-time expression formed in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, only the first one so appearing is determinative.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| page-version
| Pages may be revised several times daily. While date-time given to a granularity of a fraction of a second would often suffice, when a page has to be approved more than once before posting, any or no such time may be correct (without this keyword, a comment could be necessary but probably not parsable by an engine). In addition, versions regardless of date may show consecutiveness and can replace a date that must be vague. In that case, a version number may be more useful for searches and so a robot-parsable format is needed.<br />The keyword's value is stated in ASCII digits, is any nonnegative base-10 rational number expressed as an integer or a decimal, with any number of decimal places allowed, and may be padded with any number of leading zeros to support extraction for ASCII sorting.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />The versions 0 and 0.''n'', with ''n'' being to any number of places, signify beta versions, i.e., drafts, in the tradition of beta software, while versions 1 and higher ordinarily signify final-release versions. After a final-release version is released, a draft of a later version is not given a version number of 0 or 0.''n'', but is numbered higher than the last final-release version. It is suggested to page authors that draft status, if applicable, be shown in the visibly displayed text of the page, rather than that this meta tag be relied upon as the sole notice of draft status, as it may be inadequate notice if alone.<br />To assign a low page-version such as 0.''n'' or 1, the page's URL, if static, may be used as the relevant premise. Thus, if a page is copied or moved to a new URL, the author may choose to restart page-version numbering from 0.''n'' or 1. If a page's URL is dynamic, e.g., if created on the fly from a script, the page author may prefer to use as the relevant premise for assigning a low page-version such as 0.''n'' or 1 the URL of the script or other technology that generates the dynamic-URL page, placing this meta element containing this attribute within the script or other technology, not within the generating page's head element (the generating page's head element may have its own meta element with this attribute describing the generating page). If one page containing the script or other technology that generates another page has more than one means for generating dynamic-URL pages, each means should contain its own meta element with this attribute. Page-version is thus largely independent of the page's date, although both would likely advance roughly in parallel.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| resolutions
| Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.

To accomplish this, I propose a new HTML Meta Tag, <code>resolutions</code>, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page.

So, for example…

<code><pre><meta name="resolutions" content="2x"></pre></code>

… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix.

To illustrate, if her image tag is as follows…

<code><pre><img src="/images/flower.jpg" alt="A flower"></pre></code>

… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg.

(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)

Based on the meta tag, if the browser detects that the user is running at a <code>min-device-pixel-ratio</code> of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag.

Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.

<b>Multiple resolutions</b>

The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future.

For example:

<code><pre><meta name="resolutions" content="2x, 4x, 8x"></pre></code>

In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.

<b>Advantages</b>

The advantages of this approach are several:

<ol>
<li>Makes it very simple for developers to support high-resolution displays like the iPhone 4's Retina screen</li>
<li>Does not require JavaScript</li>
<li>Does not change the default way that things work (if the meta tag is not specified, the browser simply behaves as it always has).</li>
</ol>

| [http://aralbalkan.com/3355 Proposal for native browser support of high-resolution image substitution]
[http://aralbalkan.com/3331 How to make your web content look stunning on the iPhone 4’s new Retina display]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| rights
| As a page effectively appears in at least two forms, usually one as interpreted and displayed on a device and the other as source code, arguably intellectual property rights that must be asserted must be asserted in ways understandable in both contexts. For example, &copy; is a raw representation that may legally fail as part of copyright notice to someone seeing source code and not the display, important when someone wants to copy source code for use elsewhere and may rely on a defense of innocent infringement (at least in U.S.). While such assertions can be made in a comment element, it may be helpful to have a tag that search engines can parse and index verbatim.<br />The value may include standard and nonstandard notices, invocations of licenses such as GFDL and ASCAP, and any other information. Content is defined as free-form, leaving the page author discretion for the entry.<br />Statements in one tag may discuss several portions of the page differently, e.g., with different licenses.<br />More than one license may be offered, along with the page's relationship to all.<br />Not all statements need be license grants. A statement may state whom to ask for reprint permission or may reserve all rights, for example.<br />Only one meta tag with this keyword may be present. Page authors must not use more than one. A UA finding multiple such tags on one page must ignore all of them.<br />The copyright symbol that would be generated by its character entity is not recommended for legal notice in source code when the word 'Copyright' may be used instead, because the entity may be read in raw form, but use is up to the page author. The same concept applies to any intellectual property rights symbol for which a suitable alternative is available, such as for trademark or service mark.<br />ASCII text would not suffice when a name or notice legally may have to be in a non-Roman alphabet, but no alternative may yet exist in HTML5.<br />Search engine storage may impose a length limit, but, because of legal consequences, if the value's length exceeds a given limit the search index should retain or interpret none of it but only refer to it.<br />The content string may only be copied verbatim in its full length, referred to, or ignored. It may not be, for example, paraphrased, truncated, interpreted, or classified except in addition to being copied verbatim in its full length.<br />Ignoring shall not void, nullify, or alter any rights stated in such tag.<br />For the synonymy, ''IP'', ''IP-rights'', and ''IP-right'' are not reserved; while the abbreviation ''IP'' 'intellectual property' is common among attorneys in the U.S., page authors will more likely be computerate, and the abbreviation may be wanted for 'Internet Protocol'.
| [[Talk:MetaExtensions#rights:_why_reversion|Talk]]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| subj-. . .
| To classify by subject a page's content, a standard subject taxonomy that will be recognized by a search engine or directory will help. Because many such high-quality taxonomies exist, only a prefix is proposed. Over time, particular taxonomies, in print or online, may be recognized here and keywords assigned for each.<br />The keyword will be constructed case-insensitively with subkeywords in the form subj-[nationAbbrev]-[taxonomy]-[edition][-optionalSubedition], e.g., subj-US-MeSH-2009online (perhaps). After "subj-", the second subkeyword will identify the nation where the taxonomy is published or offered as an aid in identifying the taxonomy and does not limit the subject coverage; e.g., a taxonomy published in Japan may be ideal for classifying Canadian botany or Peruvian economy.<br />As subject values may vary between editions of one taxonomy, an edition and optionally a subedition is to be identified in the third and optionally the fourth subkeywords. The subedition, if any, is any update or revision occurring between editions, such that a value drawn from that edition and subedition is stable. The means of identifying edition and subedition should be included in the registration of a keyword.<br />Examples of taxonomies from the U.S. include MeSH (medical) and the Library of Congress Subject Headings.<br />The value identifying a subject for a Web page will be drawn from the cited taxonomy's edition and subedition.<br />If the value should have a style to prevent ambiguity in interpretation, that style is to be registered here for that keyword. Multiple values are expressed with multiple meta elements, one value for each, since comma-separation is probably not compatible with all taxonomies.<br />If a value requires case-sensitivity to prevent confusion, the entry here registering the keyword must accommodate that need with the needs of HTML 5 with an appropriate rule. To that end, a proposal to allow case-sensitivity in meta tags under some circumstances has been offered in the W3C bug reporting system.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854 W3C Bug 6854]
| subject-. . .
| Incomplete proposal
| Lacks link to a spec, tries to register a space of names instead of enumerated names

|-valign="top"
| nibbler-site-verification
| Used to verify ownership of Nibbler site
| [http://nibbler.silktide.com/ Nibbler site]
|
| Incomplete proposal
| Claimed spec link does not link to a spec

|-valign="top"
| MSSmartTagsPreventParsing
| Microsoft introduced into Internet Explorer 6 Beta a feature that some website designers wished to preclude from applying in order to prevent public misunderstanding of their websites. The feature allowed a browser to add information but at a risk that users wouldn't know that it wasn't supplied by the website. This keyword was provided by Microsoft for those of us who wanted it.<br />Its value was "TRUE". Microsoft spelled the keyword with some capitals and the value in all capitals but whether capitalization was required for either is unknown; some opinions vary. Since it need be understood by only one browser, and that one a beta version, full standards compliance should not be assumed, and original case may be required. (This tag is used by Google: "<meta content='true' name='MSSmartTagsPreventParsing'/>" appeared (with internal quote marks as singles) in the source code for <http://googleblog.blogspot.com/2009/04/listening-to-google-health-users.html>, as accessed 4-27-09.)<br />Microsoft has apparently removed this instruction from its website on the ground that the beta version is no longer available and is not supported, but that doesn't assure that some users aren't still using the beta browser, perhaps inadvertently. Therefore, designers may wish to continue using the keyword and value and they are preserved here.
| e.g., [http://www.theregister.co.uk/2001/06/25/web_sites_banish_those_winxp/ The Register (U.K.)], [http://cc.uoregon.edu/cnews/summer2001/summer2001.pdf Univ. Oregon (U.S.) (PDF p. 18)], & [http://trillian.mit.edu/~jc/demo/SmartTagsOff.html John Chambers (U.S.) (job résumé near root)], all as accessed 4-19-09
|
| Incomplete proposal
| Lacks spec, potentially never minted by MS as a meta name (as opposed to a http-equiv value), even if minted by Microsoft, abandoned before shipping in any final release of IE

|}

== Failed Proposals ==

{| class="wikitable sortable"
! Keyword
! Brief description
! Link to more details
! Synonyms
! Status

|-valign="top"
| cache
| This doesn't actually work; use HTTP headers instead.<br />Value must be "public", "private", or "no-cache". Intended as a simple way to tell user agents whether to store a copy of the document or not. An alternate for HTTP/1.1's cache-control; for publishers without access to modifying cache-control.
| none
|
| Unendorsed

|-valign="top"
| no-email-collection
| HTML5 prohibits URL-valued meta names. They should be rel keywords instead.<br />Intended to reference legal policy of web site indicating that harvesting of e-mail addresses on the site is not permitted and in violation of applicable laws such as the CAN-SPAM Act of 2003.
| [https://www.ProjectHoneyPot.org/how_to_avoid_spambots_5.php Project Honey Pot]
|
| Unendorsed

|}

== Process ==

For the "Status" section to be changed to "Ratified", the proposed keyword must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Unendorsed".

For more details, see [http://whatwg.org/specs/web-apps/current-work/#concept-meta-extensions the HTML5 specification].

[[Category:Registries]]

MetaExtensions

2013-12-10T20:57:46Z

Tantek: add mobile-web-app-capable as vendor-neutral version of apple-mobile-web-app-capable

This page lists the allowed extension values for the name="" attribute of the <meta> element in HTML5. You may add your own values to this list, which makes them legal HTML5 metadata names. We ask that you '''try to avoid redundancy'''; if someone has already defined a name that does roughly what you want, please reuse it. Also, please be sure to include ''all'' the items [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names required by the spec] ''including a link to a specification'' that specifies the keyword ''as an HTML meta keyword''. If a proposal lacks a specification and a version in a complete specification exists, the latter is to be preferred.
Note that URL-valued properties must not be registered as meta names but should be registered as [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions rel keywords] instead. Also note that changes to this registry may not be reflected in validators in real time.

== Registered Extensions ==

{| class="wikitable sortable"
! Keyword
! Brief description
! Link to specification
! Synonyms
! Status

|-valign="top"
| aafc.subject
| The topic of the resource within the Department of Agriculture and Agri-Food Canada
|
|
| Proposal

|-valign="top"
| rights
| Extra Copyright info used by Direkt SPEED and others
|
|
| Proposal

|-valign="top"
| og:site_name
| The Name of the site for OpenGraph Facebook
|
|
| Proposal

|-valign="top"
| AGLSTERMS.act
| A specific piece of legislation which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.accessibility
| A statement indicating the accessibility characteristics of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.accessMode
| Perceptual mode for the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.aggregationLevel
| The level of aggregation of the described resource - an 'item' or a 'collection'.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.availability
| How the resource can be obtained or accessed, or contact information. Primarily used for offline resources to provide information on how to obtain physical access to the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.case
| A specific piece of case law which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.category
| The generic type of the resource being described - a 'service', 'document' or 'agency'.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.dateLicensed
| Date a license was applied or became effective.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.documentType
| The form of the described resource where the value of category is‘document’. Document is used in its widest sense and includes resources such as text, images, sound files and software.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.function
| The business function to which the resource relates. Functions are the major units of activity which organisations pursue in order to meet the mission and goals of the organisation.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.isBasisFor
| A related resource that is a performance, production, derivation, translation or interpretation of the described resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.isBasedOn
| A related resource of which the described resource is a performance, production, derivation, translation or interpretation.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.jurisdiction
| The name of the political/administrative entity covered by the described resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.mandate
| A specific legal instrument which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.protectiveMarking
| A protective marking applied to the described resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.regulation
| A specific regulation which requires or drives the creation or provision of the resource.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| AGLSTERMS.serviceType
| The form of the described resource where the value of category is ‘service'.
| [http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces AGLS Terms]]
|
| Proposal

|-valign="top"
| alexaverifyid
| Used to verify ownership of Alexa Search
| [http://www.alexa.com/faqs/?p=188 Alexa FAQ About this meta attribute Reference]
|
| Proposal

|-valign="top"
| Copyright
| Used to verify Copyright of the Website
|
| <code><meta name="rights"></code> '''(already proposed but rejected because of missing spec)'''
<code><meta name="dcterms:rights"></code>
| Proposal

|-valign="top"
| Revisit
| Used to check revisit of the Website
|
| Possibly <code><meta name="revisit-after"></code>,
cookies
| Proposal

|-valign="top"
| Abstract
| Used to check the content of the Website
|
| <code><meta name="dcterms:abstract"></code>
<code><meta name="dcterms:description"></code>
| Proposal

|-valign="top"
| page-topic
| Used to check the page topic or category of the Website
|
| standard <code><meta name="description"></code>
or <code><meta name="keywords"></code>
| Proposal

|-valign="top"
| audience
| Used to clarify the audience or category page traffic for the Website
|
| <code><meta name="dcterms:audience"></code>
Already existing, but '''rejected because of missing spec'''
| Proposal

|-valign="top"
| tysontcsverid
| Used to verify ownership of Website for TCS webmaster tools
| [http://www.tysontcs.co.uk/Veridspec.html Livechat About this meta attribute Reference]
|
| Proposal

|-valign="top"
| apple-itunes-app
| Promoting Apps with Smart App Banners
| [http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html Safari Web Content Guide]
|
| Proposal

|-valign="top"
| apple-mobile-web-app-capable
| Sets whether a web application runs in full-screen mode.
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]
| mobile-web-app-capable (also could maybe be assumed when <code>application-name</code> is set?)
| Proposal

|-valign="top"
| apple-mobile-web-app-status-bar-style
| Sets the style of the status bar for a web application.
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]
|
| Proposal

|-valign="top"
| apple-touch-fullscreen
| Makes WebApp Fullscreen (With iPhone 5 Support)
| No specification yet
|
| Proposal

|-valign="top"
| apple-mobile-web-app-title
| Sets the title of the application when added to the homescreen on iOS6+
| No specification yet
|
| Proposal

|-valign="top"
| application-url
| '''Start URL of web apps in Google Chrome'''
The "application-url" meta tag can be used to specify the start URL of pinned web apps in Google Chrome.
<meta name="application-url" content="https://gmail.com/">
| [http://www.google.com/chrome/intl/en/webmasters-faq.html#customshortcuts Google Chrome Webmaster FAQ] [http://code.google.com/p/chromium/issues/detail?id=40010#c1 Chromium issue response]
|
| Proposal

|-valign="top"
| baiduspider
| Synonym of <code>robots</code> for targeting Baidu only.
| [http://www.baidu.com/search/robots_english.html Baidu documentation]
|
| Proposal

|-valign="top"
| bitcoin
| A Bitcoin address
| [https://en.bitcoin.it/wiki/Address Bitcoin address on the Bitcoin wiki]
|
| Proposal

|-valign="top"
| cfia.gdr.include
| Canadian Food Inspection Agency Guidance Document Repository Page
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| cfia.gdr.program
| Canadian Food Inspection Agency Guidance Document Repository Page Program
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| cfia.gdr.commodity
| Canadian Food Inspection Agency Guidance Document Repository Page Commodity
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| cfia.gdr.activity
| Canadian Food Inspection Agency Guidance Document Repository Page Activity
| Coming soon at [http://www.inspection.gc.ca CFIA website]
|
| Proposal

|-valign="top"
| citeseerxbot
| Synonym of <code>robots</code> for targeting CiteSeerX only.
| [http://csxstatic.ist.psu.edu/submit CiteSeerX Submit Documents] <small>'If you do not want your documents crawled by CiteSeerX, please use a robots.txt to disallow our crawler named "citeseerxbot"'</small>, [http://csxstatic.ist.psu.edu/about/crawler CiteSeerX Crawler]
|
| Proposal

|-valign="top"
| collection
| To replace the obsolete dc:collection. A collection is described as a group, an aggregation of topics Used to describe the top-level content of XHTML documents. These appear in your META tags showing a group of subject. Website Taxonomy improve classification for search engine analysis and semantic communication with a description language content.

<meta name="collection" content="MetaExtensions" />
<meta name="subject" content="topics, thesaurus, Meta Tag, header, semantic" />
| [http://www.trucsweb.com/tw/]
|
| Proposal

|-valign="top"
| csrf-param
| Cross-site request forgery protection parameter for Ruby on Rails
| [http://apidock.com/rails/ActionView/Helpers/CsrfHelper/csrf_meta_tag Rails API]
|
| Proposal

|-valign="top"
| csrf-token
| Cross-site request forgery protection token for Ruby on Rails
| [http://apidock.com/rails/ActionView/Helpers/CsrfHelper/csrf_meta_tag Rails API]
|
| Proposal

|-valign="top"
| da_anonymiseIP
| Defines anonymiseIP parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactCompany
| Defines the contactCompany of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactEmail
| Defines the contactEmail of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactFirstName
| Defines the contactFirstName of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactLastName
| Defines the contactLastName of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactName
| Defines the contactName of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_contactTelephone
| Defines the contactTelephone of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_conversionCurrency
| Defines the conversionCurrency of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_conversionId
| Defines the conversionId of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_conversionValue
| Defines the conversionValue of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_goalCurrency
| Defines the goalCurrency of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_goalId
| Defines the goalId of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_goalValue
| Defines the goalValue of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_interactionSelector
| Defines the interactionSelector parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageRole
| Defines the role of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageTaxonomy
| Defines the taxonomy of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageTitle
| Defines the pageTitle of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_pageVersion
| Defines the pageVersion of the page for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_sessionId
| Defines the sessionId parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| da_userId
| Defines the userId parameter for Decibel Insight
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]
|
| Proposal

|-valign="top"
| dc.date.issued
| Date of publication for Google News. The format of the content is YYYY-MM-DD or YYYY-MM-DDThh:mm:ssTZD.
It must be accompanied by a <code><link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"></code> element
| [http://www.google.com/support/news_pub/bin/answer.py?answer=93994 Google News documentation]
| <code>dcterms.issued</code> (former <code><time pubdate></code> no longer considered due to the abort of <code>@pubdate</code>)
| Proposal

|-valign="top"
| dc.language
| A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646].
It must be accompanied by a <code><link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-language DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| Redundant with the <code>lang</code> attribute on the
<code>html</code> element. (Browsers pay attention to the <code>lang</code> attribute but not <code>dc.language</code>)
| Proposal

|-valign="top"
| dcterms.abstract
| A summary of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-abstract DCMI
Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| <code><meta name="description"></code>
| Proposal

|-valign="top"
| dcterms.accessRights
| Information about who can access the resource or an indication of its security status.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accessRights DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.accrualMethod
| The method by which items are added to a collection.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualMethod DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.accrualPeriodicity
| The frequency with which items are added to a collection.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualPeriodicity DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.accrualPolicy
| The policy governing the addition of items to a collection.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualPolicy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.alternative
| An alternative name for the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-alternative DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.audience
| A class of entity for whom the resource is intended or useful.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-audience DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.available
| Date (often a range) that the resource became or will become available.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-available DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.bibliographicCitation
| A bibliographic reference for the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-bibliographicCitation DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML attribute <code>cite</code>
| Proposal

|-valign="top"
| dcterms.collection
| An aggregation of resources.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#dcmitype-Collection DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.conformsTo
| An established standard to which the described resource conforms.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-conformsTo DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.contributor
| An entity responsible for making contributions to the content of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-contributor DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.coverage
| The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-coverage DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.created
| Date of creation of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-created DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.creator
| An entity primarily responsible for making the resource. Examples of a Creator include a person, an organization, or a service.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-creator DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| In some cases redundant with the HTML built-in keyword <code>author</code>
| Proposal

|-valign="top"
| dcterms.date
| A point or period of time associated with an event in the lifecycle of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-date DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.dateAccepted
| Date of acceptance of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-dateAccepted DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.dateCopyrighted
| Date of copyright.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-dateCopyrighted DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.dateSubmitted
| Date of submission of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-dateSubmitted DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.description
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-description DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in keyword <code>description</code>
| Proposal

|-valign="top"
| dcterms.educationLevel
| A class of entity, defined in terms of progression through an educational or training context, for which the described resource is intended.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-educationLevel DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.extent
| The size or duration of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-extent DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.format
| The file format, physical medium, or dimensions of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-format DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| To be limited to dimensions information. File format for the document is to be determined by server. Linked resources can be described by <code>type</code> attribute.
| Proposal

|-valign="top"
| dcterms.hasFormat
| A related resource that is substantially the same as the pre-existing described resource, but in another format.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-hasFormat DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.hasPart
| A related resource that is included either physically or logically in the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-hasPart DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.hasVersion
| A related resource that is a version, edition, or adaptation of the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-hasVersion DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.identifier
| An unambiguous reference to the resource within a given context.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-identifier DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.instructionalMethod
| A process used to engender knowledge, attitudes and skills, that the described resource is designed to support.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-instructionalMethod DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.isFormatOf
| A related resource that is substantially the same as the described resource, but in another format.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isFormatOf DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.isPartOf
| A related resource in which the described resource is physically or logically included.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isPartOf DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.isReferencedBy
| A related resource that references, cites, or otherwise points to the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isReferencedBy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.isReplacedBy
| A related resource that supplants, displaces, or supersedes the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isReplacedBy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.isRequiredBy
| A related resource that requires the described resource to support its function, delivery, or coherence.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isRequiredBy DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.issued
| Date of formal issuance (e.g., publication) of the resource. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.)
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-issued DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| (former <code><time pubdate></code> no longer considered due to the abort of <code>@pubdate</code>)
| Proposal

|-valign="top"
| dcterms.isVersionOf
| A related resource of which the described resource is a version, edition, or adaptation.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-isVersionOf DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.language
| A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646].
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-language DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| Redundant with the <code>lang</code> attribute on the <code>html</code> element. (Browsers pay attention to the <code>lang</code> attribute but not <code>dcterms.language</code>)
| Proposal

|-valign="top"
| dcterms.license
| A legal document giving official permission to do something with the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-license DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML <code><link></code> element with the keyword <code>"license"</code> as value of the <code>rel</code> attribute.
| Proposal

|-valign="top"
| dcterms.mediator
| An entity that mediates access to the resource and for whom the resource is intended or useful.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-mediator DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.medium
| The material or physical carrier of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-medium DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.modified
| Date on which the resource was changed. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.)
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-modified DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.provenance
| A statement for any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-provenance DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.publisher
| An entity responsible for making the resource available.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-publisher DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.references
| A related resource that is referenced, cited, or otherwise pointed to by the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-references DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| <code>cite</code> attribute on specific quotes, if any.
| Proposal

|-valign="top"
| dcterms.relation
| A related resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-relation DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| If the relation comes from an internal reference or quote, <code>dcterms.references</code> should be preferred.
| Proposal

|-valign="top"
| dcterms.replaces
| A related resource that is supplanted, displaced, or superseded by the described resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-replaces DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code>
| Proposal

|-valign="top"
| dcterms.requires
| A related resource that is required by the described resource to support its function, delivery, or coherence.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-requires DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.rights
| Information about rights held in and over the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-rights DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML <code><link></code> element with the keyword <code>"license"</code> as value of the <code>rel</code> attribute, if referring to a legal license format.
| Proposal

|-valign="top"
| dcterms.rightsHolder
| A person or organization owning or managing rights over the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-rightsHolder DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.source
| A related resource from which the described resource is derived.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-source DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code> if documents are different versions. Otherwise, <code>cite</code> attribute.
| Proposal

|-valign="top"
| dcterms.spatial
| Spatial characteristics of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-spatial DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.subject
| The topic of the resource.
| [http://dublincore.org/documents/dcmi-terms/#terms-subject DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in keywords <code>description</code> or <code>keywords</code>
| Proposal

|-valign="top"
| dcterms.tableOfContents
| A list of subunits of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-tableOfContents DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in keywords <code>description</code> or <code>keywords</code>. Otherwise, a <code>details-summary</code> model which would provide user-readable information.
| Proposal

|-valign="top"
| dcterms.temporal
| Temporal characteristics of the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-temporal DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.title
| A name given to the resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-title DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
| HTML built-in element <code>title</code> (not to be confused with <code>@title</code> attributes specific to each element)
| Proposal

|-valign="top"
| dcterms.type
| The nature or genre of the resource.
| [http://dublincore.org/documents/dcmi-terms/#terms-type DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| dcterms.valid
| Date (often a range) of validity of a resource.
It must be accompanied by a <code><link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"></code> element.
| [http://dublincore.org/documents/dcmi-terms/#terms-valid DCMI Metadata Terms] mapped according to
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]
|
| Proposal

|-valign="top"
| designer
| Credits the designer(s) responsible for the visual presentation of a website.
| [https://sites.google.com/site/metadesignerspec/ Documentation]
|
| Proposal

|-valign="top"
| entity
| Allows for definitions of XML-style entities for substitution of references (defined as specially-named elements (e.g., use of data element and/or data-* attribute) or script tags) via inclusion of a JavaScript library. Library also supports inclusion of additional meta element entity definitions via iframe documents.
| [https://github.com/brettz9/js-css-entities Documentation]
|
| Proposal

|-valign="top"
| EssayDirectory
| Defines a custom description of websites listed in EssayDirectory.<br>Example:
<meta name="EssayDirectory" content="Helping students find legitimate essay services.">
| [http://essaydirectory.com/privacy-terms/#EssayDirectory_MetaExtension Documentation]
|
| Proposal

|-valign="top"
| fdse-description
| Tag used by FDSE search software, allows different description to be displayed in fdse results to that shown in description
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| fdse-index-as
| Tag used by FDSE search software, allows FDSE to index a page as url described here
| [http://www.xav.com/scripts/search/help/1014.html]
|
| Proposal

|-valign="top"
| fdse-keywords
| Tag used by FDSE search software, allows different keywords to be used by FDSE to keywords tag
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| fdse-refresh
| Tag used by FDSE search software, allows FDSE to ignore refresh meta tags
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| fdse-robots
| Tag used by FDSE search software, allows different robots instructions to be sent to FDSE than that sent to other search engines eg: index no index pages for local search
| [http://www.xav.com/scripts/search/help/1013.html]
|
| Proposal

|-valign="top"
| gcterms.topicTaxonomy
| Organize resources specifically for taxonomy-based topical browse or search structures on websites (ie: breadcrumbs / website information architecture).
| [http://www.gcpedia.gc.ca/wiki/Metadata_Tools#Metadata_for_Web_Resource_Discovery] Government of Canada, Web Content Management System Metadata Application Profile.
|
| Proposal

|-valign="top"
|icas.datetime.long
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of ICAS long date format such as "UCN 12012 M03 Blue ❀ day 333 ❀ IDC zone(UT) t969 tt189". example <meta name="icas.datetime.long" content="UCN 12012 M03 Blue ❀ day 333 ❀ IDC zone(UT) t969 tt189"/>
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
|icas.datetime.day
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of ICAS day-of-year format such as "2012 day 333 t969".
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
|icas.datetime.abbr
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of an ICAS abbreviated format such as "d2M03 t969".
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
|icas.datetime
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of an ICAS date and time format of unspecified information density (may include full, long, medium, short, or compressed forms).
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.
|
|proposal

|-valign="top"
| publisher
| Searching for one content publisher's or page publisher's work requires a standard robot-parsable format for the information. This often differs from creator or author when the publisher is an institution. An institutional name, personal name, or other text entry is permissible.<br />One element represents only one publisher. Multiple publishers are to be represented with multiple tags, although multiple publishers are less common than multiple authors or creators; multiplicity is more likely for a legal name and a well-known name.<br />Search engines may index by any component of a name, so a publisher need only enter a name once in one order.
| defacto standard, used in nearly every website, e.g. [http://www.gaijin.at/olsmgen.php][http://developers.evrsoft.com/metagen.shtml][http://www.html-seminar.de/metatags.htm]
|
| Proposal

|-valign="top"
| review_date
| The date a resource is scheduled for review by content creator in order to determine if it should be archived, updated or retained as is.
| [http://www.hc-sc.gc.ca/home-accueil/alt_formats/pacrb-dgapcr/pdf/Metadata_Application_Profile_2009.pdf Health Canada Web Metadata Application Profile March 2009 ]
|
| Proposal

|-valign="top"
| e-mailit-site-verification
| Used to verify ownership for E-MAILiT share buttons.
| [http://www.e-mailit.com/ E-MAILiT share buttons]
|
| Proposal

|-valign="top"
| es.title
| Object Title, where this is not the TITLE or H1 tag content, but the resource title
| [http://www.eibs.co.uk/reference/ EIBS EasySite CMS - Content Attributes Reference]
| dcterms.title
| Proposal

|-valign="top"
| format-detection
| Enables or disables automatic detection of possible phone numbers in a webpage in Safari on iOS.
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]
|
| Proposal

|-valign="top"
| fragment
| Opts a webpage into the AJAX crawling scheme when it does not have a "#!" URL. The only valid content value is "!".
<meta name="fragment" content="!">
| [https://developers.google.com/webmasters/ajax-crawling/docs/specification Google Crawable AJAX Specification]
|
| Proposal

|-valign="top"
| geo.position
| Geographic position to which the page is related.
<meta name="geo.position" content="48.02682000000001;7.809769999999958">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]
| icbm (different value syntax)
| Proposal

|-valign="top"
| geo.country
| Case-insensitive ISO 3166-1 alpha-2 code of a country to which the page is related.
<meta name="geo.country" content="de">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>[http://en.wikipedia.org/wiki/ISO_3166-2 ISO-3166-2]
|
| Proposal

|-valign="top"
| geo.a1
| National subdivision (state, canton, region, province, prefecture) of civil address to which the page is related. For resources within the US and Canada, corresponds to the common 2-character State/Province codes.
<meta name="geo.a1" content="AB">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776
|
| Proposal
|-valign="top"
| geo.a2
| County, parish, gun (JP), district (IN) of civil address to which the page is related.
<meta name="geo.a2" content="Warwickshire">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776
|
| Proposal
|-valign="top"
| geo.a3
| City, township, shi (JP) of civil address to which the page is related.
<meta name="geo.a3" content="Calgary">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776
|
| Proposal

|-valign="top"
| geo.lmk
| A landmark or vanity address to which the page is related.
<meta name="geo.lmk" content="Auwaldstraße 11, 79110 Freiburg im Breisgau, Deutschland">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]
|
| Proposal

|-valign="top"
| geo.region
| Superseded by either geo.country alone or geo.country plus geo.a1. Name of geographic region to which the page is related. Content is specified by ISO-3166.
<meta name="geo.region" content="DE-BW">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>[http://en.wikipedia.org/wiki/ISO_3166 ISO-3166]
|
| Proposal

|-valign="top"
| geo.placename
| Superseded by geo.lmk. Name of geographic place to which the page is related.
<meta name="geo.placename" content="London, Ontario">
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]
|
| Proposal

|-valign="top"
| go-import
| Defines a remote source code location and version control scheme for the Go programming language's toolchain. Content format: <code>import-prefix vcs repo-root</code>.
| [http://golang.org/cmd/go/#hdr-Remote_import_path_syntax go tool documentation]
|
| Proposal

|-valign="top"
| google-site-verification
| Used to verify ownership for Webmaster Tools.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=79812 Google documentation]
|
| Proposal

|-valign="top"
| google-translate-customization
| Used to verify ownership for Website Translator.
| [http://googlewebmastercentral.blogspot.co.nz/2012_05_01_archive.html Google documentation]
|
| Proposal

|-valign="top"
| verify-v1
| Superseded by google-site-verification. Legacy verification for Google Sitemaps.
| [http://sitemaps.blogspot.com/2006/05/more-about-meta-tag-verification.html Inside Google Sitemaps: More about meta tag verification]
|
| Proposal

|-valign="top"
| google
| A content of "notranslate" will tell google not to pop up the translate bar / link if the page is in a foreign language form the user's browser.
<meta name="google" content="notranslate">
| [http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html Google blog post]
|
| Proposal

|-valign="top"
| googlebot
| Synonym of <code>robots</code> for targeting Googlebot only.
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=93710 Google documentation]
|
|Proposal

|-valign="top"
| googlebot-mobile
| Synonym of <code>robots</code> for targeting Googlebot-Mobile
| [https://developers.google.com/webmasters/smartphone-sites/googlebot-mobile]
|
| Proposal

|-valign="top"
| revisit-after
| revisit-after is used to tell search engines how often to recrawl the page. To our knowledge only one search engine has ever supported it, and that search engine was never widely used — at this point, it is nothing more than a good luck charm.
| [http://code.google.com/webstats/2005-12/metadata.html Google documentation]
|
| Proposal

|-valign="top"
| icbm
| Defines geographic position to which page is related to. The acronym stands for ICBM Intercontinental Ballistic Missile - an old, humorous allusion to the possible use of such coordinates.<br>Example:
<meta name="ICBM" content="47.0667, 15.4500" />
| [http://geourl.org/add.html GeoURL documentation]
| geo.position (different value syntax)
| Proposal

|-valign="top"
| HandheldFriendly
| Denotes handheld-friendly content
| [http://learnthemobileweb.com/tag/handheldfriendly/]
|
| Proposal

|-valign="top"
| markosweb.com/validation
| Used to verify ownership of Markosweb.com
| [http://www.markosweb.com/help/ownership/ Markosweb Validation Help]
|
| Proposal

|-valign="top"
| mobile-web-app-capable
| Sets whether a web application can be added standalone to a home screen and launched in fullscreen mode. Also proposed as a vendor-neutral version of apple-mobile-web-app-capable.
| [https://developers.google.com/chrome/mobile/docs/installtohomescreen Add to Homescreen - Google Chrome Mobile — Google Developers] (though a WHATWG or W3C spec would be preferred)
| apple-mobile-web-app-capable (vendor specific synonym)
| Proposal

|-valign="top"
| StartVer
| Used to verify Websites for Start!-App
| No specification yet
|
| Proposal

|-valign="top"
| MobileOptimized
| Denotes content optimized for mobile browsers
| [http://learnthemobileweb.com/tag/mobileoptimized/]
|
| Proposal

|-valign="top"
| itemsPerPage
| Used to identify the number of search results returned per page.
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]
|
| Proposal

|-valign="top"
| msapplication-task
| '''"Jump List" or "Pinned Sites" in Windows 7'''
Jump List items act as entry points into the website even when the browser is not running. A Jump List can contain commonly used destinations and tasks. Some items apply to the whole site, and some apply only to specific users.
For example, to add a single task called "Check Order Status" specify a meta element in the head of your webpage, as follows:
<META name="msapplication-task" content="name=Check Order Status;
action-uri=./orderStatus.aspx?src=IE9;
icon-uri=./favicon.ico" />
| [http://msdn.microsoft.com/en-us/library/gg491725(v=vs.85).aspx Tasks in Jump List]
|
| Proposal

|-valign="top"
| msapplication-starturl
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-starturl" metadata contains the root URL of the application. The start URL can be fully qualified, or relative to the current document. Only HTTP and HTTPS protocols are allowed. If this element is missing, the address of the current page is used instead.
<meta name="msapplication-starturl" content="./" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-tooltip
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-tooltip" metadata provides additional tooltip text that appears when you hover over the Pinned Site shortcut in the Windows Start menu or on the desktop.
<meta name="msapplication-tooltip" content="Channel 9 Podcasts" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-tap-highlight
| '''Link highlighting in Internet Explorer'''
The "msapplication-tap-highlight" meta tag can be used to disable automatic highlighting of tapped links in Internet Explorer. Applies to IE10 on Windows Phone 8 and IE11 on Windows 8.1.
<meta name="msapplication-tap-highlight" content="no" />
| [http://msdn.microsoft.com/en-us/library/ie/bg182645%28v=vs.85%29.aspx#tapHighlight Link highlighting]
|
| Proposal

|-valign="top"
| msapplication-navbutton-color
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-navbutton-color" metadata define the custom color of the Back and Forward buttons in the Pinned Site browser window. Any named color, or hex color value is valid.
<meta name="msapplication-navbutton-color" content="#FF3300" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-window
| '''"Jump List" or "Pinned Sites" in Windows 7'''
The "msapplication-window" metadata sets the initial size of the Pinned Site window when it is launched for the first time. However, if the user adjusts the size of the window, the Pinned Site retains the new dimensions when it is launched again.
The following properties can be used in the value of the <code>content</code> attribute:
* width - The window width in pixels. The minimum value is 800.
* height - The window height in pixels. The minimum value is 600.
<meta name="msapplication-window" content="width=1024;height=768" />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]
|
| Proposal

|-valign="top"
| msapplication-TileImage
| The "msapplication-TileImage" metadata define the path to an image to be used as background for a tile in Pinned Sites in Windows 8. Tile images must be square PNGs 144px by 144px.
<meta name="msapplication-TileImage" content="images/benthepcguy-144.png" />
| [http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx High Quality Visuals for Pinned Sites in Windows 8]
|
| Proposal

|-valign="top"
| msapplication-TileColor
| The "msapplication-TileColor" metadata define the background color of a tile in Pinned Sites in Windows 8. The tile color can be specified as a hex RGB color using CSS’s #rrggbb notation, via CSS color names, or by the CSS rgb() function.
<meta name="msapplication-TileColor" content="#d83434"/>
| [http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx High Quality Visuals for Pinned Sites in Windows 8]
|
| Proposal

|-valign="top"
| msapplication-square70x70logo
| '''msapplication-square70x70logo'''
Specifies the image to use as the small tile, which is 70x70 pixels at 100% scaling.
<meta name="msapplication-square70x70logo" content="images/tinylogo.png">
'''Note''' The '''msapplication-square70x70logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msapplication-square150x150logo
| '''msapplication-square150x150logo'''
Specifies the image to use as the wide tile, which is 310x150 pixels at 100% scaling.
<meta name="msapplication-square150x150logo" content="images/logo.png">
'''Note''' The '''msapplication-square150x150logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msapplication-wide310x150logo
| '''msapplication-wide310x150logo'''
Specifies the image to use as the medium tile, which is 150x150 pixels at 100% scaling.
<meta name="msapplication-wide310x150logo" content="images/widelogo.png">
'''Note''' The '''msapplication-wide310x150logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msapplication-square310x310logo
| '''msapplication-square310x310logo'''
Specifies the image to use as the large tile, which is 310x310 pixels at 100% scaling.
<meta name="msapplication-square310x310logo" content="images/largelogo.png">
'''Note''' The '''msapplication-square310x310logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]
|
| Proposal

|-valign="top"
| msvalidate.01
| One of the verification elements used by Bing.
| [http://onlinehelp.microsoft.com/en-us/bing/hh204490.aspx Bing Webmaster Tools]
|
| Proposal

|-valign="top"
| og:audio
| A URL to an audio file to accompany this object.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:description
| A one to two sentence description of your object.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:determiner
| The word that appears before this object's title in a sentence. An enum of (a, an, the, "", auto). If auto is chosen, the consumer of your data should chose between "a" or "an". Default is "" (blank).
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:image
| An image URL which should represent your object within the graph.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:locale
| The locale these tags are marked up in. Of the format language_TERRITORY. Default is en_US.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:locale:alternate
| An array of other locales this page is available in.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:site_name
| If your object is part of a larger web site, the name which should be displayed for the overall site. e.g., "IMDb".
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:title
| The title of your object as it should appear within the graph, e.g., "The Rock".
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:type
| The type of your object, e.g., "video.movie". Depending on the type you specify, other properties may also be required.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:url
| The canonical URL of your object that will be used as its permanent ID in the graph, e.g., "http://www.imdb.com/title/tt0117500/".
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| og:video
| A URL to a video file that complements this object.
| [http://ogp.me/ The Open Graph protocol]
|
| Proposal

|-valign="top"
| norton-safeweb-site-verification
| Used to verify ownership of Website for Norton SafeWeb.
| [http://safeweb.norton.com/help/site_owners#verification_tips Norton SafeWeb Help Documentation]
|
| Proposal

|-valign="top"
| pinterest
| Used to block pinterest from linking to content on the URL.
Example:
<code><meta name="pinterest" content="nopin"/></code>
| [https://support.pinterest.com/entries/21101932-what-if-i-don-t-want-images-from-my-site-to-be-pinned Pinterest Help Article]
|
| Proposal

|-valign="top"
| rating
| The Restricted to Adults label (RTA) provides a way for adult oriented websites to indicate that their content is off limits to children. RTA was introduced in 2006 and is currently used by a large number of adult web content providers. RTA is recognized by all major parental control filters.
Example:
<meta name="RATING" content="RTA-5042-1996-1400-1577-RTA" />
| [http://www.rtalabel.org/index.php?content=howto RTA documentation]

|
| Proposal
|-valign="top"
| referrer
| Controls whether the user agent includes the Referer header in HTTP requests originating from this document
| [http://wiki.whatwg.org/wiki/Meta_referrer Meta referrer]
|
| Proposal

|-valign="top"
| RepostUsAPIKey
| Used to verify ownership of Website for Repost syndication service
| [http://www.repost.us/meta-headers-used-by-repost/ Meta Headers used by Repost]
|
| Proposal

|-valign="top"
| ResourceLoaderDynamicStyles
| [[mw:|MediaWiki]]'s [[mw:ResourceLoader|ResourceLoader]] uses this name with <code>content</code> set to the empty string. The purpose is to mark the DOM position before which dynamic styles should be added.
| [[mw:ResourceLoader/ResourceLoaderDynamicStyles specification|ResourceLoaderDynamicStyles]]
|
| Proposal
|-valign="top"
| rights-standard
| The purpose is to enable search engines and other cataloging services to compile the types of rights allocated to the work. (Does any search engine actually implement this? [[User:Hsivonen|hsivonen]] 07:34, 14 July 2011 (UTC))

'''This keyword does not provide, remove or alter any legal protections or designations.'''

Format:
<pre><meta name="rights-standard" content="element id;rights" /></pre>

* element id - the HTML Element ID of the item these rights apply to
* rights - what rights are assigned to the item
** "pd" - Public domain
** "cc by-sa" - Creative Commons Attribution
** "cc by-nd" - Creative Commons NoDerivs
** "cc by-nc" - Creative Commons Attribution-NonCommercial
** "cc by-nc-sa" - Creative Commons Attribution-NonCommercial-ShareAlike
** "cc by-nc-nd" - Creative Commons Attribution-NonCommercial-NoDerivs

| [http://sites.google.com/site/metarightsstandard/ Spec]
|Redundant with [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#licensing-works Microdata vocabulary for licensing works].
|Proposal

|-valign="top"
| robots
| A comma-separated list of operators explaining how search engine crawlers should treat the content. Possible values are "noarchive" to prevent cached versions, "noindex" to prevent indexing, and "nofollow" works as the link rel value with the same name. This meta name is already supported by every popular search engine.<br />The content value "NOODP" has been offered elsewhere, so I'm proposing it here. It blocks robots from using [http://www.dmoz.org Open Directory Project] descriptions of a website instead of Web pages' own meta descriptions. It may have been introduced by Microsoft.<br />The content value "NOYDIR" has been offered by Yahoo, so I'm proposing it here. It blocks Yahoo's robot from using the Yahoo directory's descriptions of a website instead of Web pages' own meta descriptions. Whether any other robot supports this is unknown but possibly no other search engine uses Yahoo's directory anyway.
| [http://www.robotstxt.org/wc/exclusion.html#meta Robots exclusion protocol], NOODP value: [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35264 Google], [http://help.yahoo.com/l/us/yahoo/search/indexing/indexing-11.html Yahoo], NOYDIR value: [http://ysearchblog.com/2007/02/28/yahoo-search-support-for-noydir-meta-tags-and-weather-update/ Yahoo], as accessed 4-28-09
|
| Proposal

|-valign="top"
| rpuPlugin
| Version of installed Repost syndication service plugin
| [http://www.repost.us/meta-headers-used-by-repost/ Meta Headers used by Repost]
|
| Proposal

|-valign="top"
| skype_toolbar
| Prevents the Skype browser extension from automatically seeking through the page and replacing telephone numbers (or any number the program's algorithm thinks is a telephone number) with its own custom presentation that allows direct invocation of the Skype program to call the telephone number.

Example:
<meta name="skype_toolbar" content="skype_toolbar_parser_compatible" />
| [http://skype.otherlinks.co.uk/page.asp?id=toolbar_number_formatting Skype Info]
|
| Proposal

|-valign="top"
| slurp
| Synonym of <code>robots</code> for targeting Yahoo! only.
| [http://help.yahoo.com/l/au/yahoo7/search/indexing/indexing-11.html Yahoo! documentation]
|
| Proposal

|-valign="top"
| startIndex
| Used to identify the index of the first search result in the current set of search results.
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]
|
| Proposal

|-valign="top"
| teoma
| Synonym of <code>robots</code> for targeting Teoma and Ask.com only.
| [http://about.ask.com/en/docs/about/webmasters.shtml Ask.com documentation]
|
| Proposal

|-valign="top"
| totalResults
| Used to identify the number of search results available for the current search.
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]
|
| Proposal

|-valign="top"
| <span id="viewport">viewport</span>
| Provides a way for documents to specify (using markup rather than CSS) the size, zoom factor, and orientation of the viewport that is used as the base for the document's [http://www.w3.org/TR/CSS21/visudet.html#containing-block-details initial containing block]. The following properties can be used in the value of the <code>content</code> attribute:
* width
* height
* initial-scale
* minimum-scale
* maximum-scale
* user-scalable
Examples:
<meta name="viewport" content="initial-scale=1.0">
<meta name="viewport" content="width=480, initial-scale=2.0, user-scalable=1">
For more details, see the [http://dev.w3.org/csswg/css-device-adapt/#viewport-meta-element Viewport META element] section of the [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] draft specification.
| For <code>meta</code> elements that have a <code>name</code> attribute whose value is <code>viewport</code>, the [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] draft specification defines the recognized properties for the <code>content</code> attribute>, as well as an algorithm for parsing the value of that attribute.
|
| Proposal

|-valign="top"
| wt.cg_n
| '''Name of the Content Group'''
Used to configure the appropriate Webtrends advanced feature. These are just some of the more popular ones. These appear in your META tags. – showing you the web page, the source (meta tag), the log files entry and the subsequent WT report.
Example:
<meta name="wt.cg_n" content="My content">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.cg_s
| '''Name of Content Sub-Group'''
Used to configure the appropriate Webtrends advanced feature. These are just some of the more popular ones. These appear in your META tags. – showing you the web page, the source (meta tag), the log files entry and the subsequent WT report.
Example:
<meta name="wt.cg_s" content="My content">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| WT.si_n
| '''Scenario analysis parameter - scenario name'''
This defines a scenario name for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends.
Example:
<meta name="WT.si_n" content="my_scenario_name">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].
|
| Proposal

|-valign="top"
| WT.si_p
| '''Scenario analysis parameter - scenario step name'''
This defines a scenario step name for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends. It works when paired with metedata tag name WT.si_n.
Example:
<meta name="WT.si_p" content="my_scenario_step_name">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].
|
| Proposal

|-valign="top"
| WT.si_x
| '''Scenario analysis parameter - scenario step number'''
This defines a scenario step number for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends. It works when paired with metedata tag name WT.si_n, and as an alternative to Wt.si_p.
Example:
<meta name="WT.si_x" content="my_scenario_step_number">
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].
|
| Proposal

|-valign="top"
| wt.ac
| '''Advertising Click parameter'''
When a visitor to your site clicks on an ad, that action is referred to as an Ad Click. The following META tag tracks advertising clicks:
<META NAME="WT.ac" CONTENT="name">
Defines the name of the advertisement clicked to reach a particular web page. The Ad Click must contain an external redirect back to the client. The redirect needs to include the necessary code to generate a hit to the SDC server. You can designate multiple Advertising Clicks using semicolons.
Examples:
<a href="file111.html?WT.ac=CONTENT111">
<a href="file222.html?WT.ac=CONTENT222">
The name of the advertisement clicked to reach a particular web page. To capture this information with DCS, the Advertising Click must contain an external redirect back to the client. The redirect needs to

include the necessary code to generate a hit to the DCS. The maximum length for each name is 64 bytes.
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.ad
| '''Advertising View parameter'''
Visitors often view advertisements that they do not necessarily click on. You can use On-Site Advertising to determine the number of visitors to your web site who view particular ads. With this feature you can produce advertising reports for each of your clients.
If you are selling advertising space on your web site, for example, you can collect traffic statistics to help determine pricing schedules.
The following META tag tracks advertising views:
<meta name="WT.ad" content="My content">
An Ad View occurs when a visitor views a page containing an ad. An ad is a link or graphic that contains an Ad Click parameter in the query portion of it's URL.
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.mc_id
| '''Identifies the ID of the marketing campaign'''
To attract new students, a university launches a marketing campaign by sending recruitment email to all graduating high school seniors in a metropolitan area. The email links to a special landing page in the university’s web site, containing the following META tag to track marketing campaigns.
Example:
<META NAME="WT.mc_id" CONTENT="1X2GG34">
You may use this parameter on the URL.
Example:
<a href="link?WT.mc_id=1X2GG34">
The Campaign ID 1X2GG34 represents recruits to be contacted by email
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| wt.sv
| '''Tracking Servers parameter'''
If your site is hosted on multiple servers, a server cluster, or a server farm, and you want to evaluate the performance of your load balancer, Webtrends can track page views for each server. To do so, populate the following META tag on all pages on each server:
Example:
<meta name="WT.sv" content="My Server">
Defines the name of the machine that serves the web page. If you have two servers (Server1 and Server2), you would make two copies of the META tag and designate CONTENT=“Server1” for deployment to pages on the first server and CONTENT=“Server2” for deployment to the same pages on the second server.
For a server farm, you can extract the value of the built-in server name and dynamically assign it to the
META tag using server-side scripting.
Example:
<meta name="WT.sv" content="Server1">
<meta name="WT.sv" content="Server2">
An Ad View occurs when a visitor views a page containing an ad. An ad is a link or graphic that contains an Ad Click parameter in the query portion of it's URL.
| [https://tagbuilder.webtrends.com/Help/Miscellaneous/AdSearch.aspx?keepThis=true&TB_iframe=true&height=450&width=650 About WT.ad].
|
| Proposal

|-valign="top"
| wt.ti
| '''Tracking Page Titles'''
You may want to modify a page title before sending it to Webtrends in the following cases:
* You are dealing with dynamic content pages identified by URL parameters, and the page title represents the title of the base URL page rather than the dynamic content page.
Unless you modify the page titles, all pages have the same title in the reports.
* All pages have been assigned the same title, for reasons of style or company policy.
Even though URLs are displayed in addition to page title, the entire URL cannot be depended upon to distinguish one page from another.
Use server-side scripts to change the title to something that reflects the content of the pages so that you can identify them in reports. Next, pass the customized page titles to Webtrends, using the following META tag:
<META NAME="WT.ti" CONTENT="title">
Defines the name of the title for this page.
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]
|
| Proposal

|-valign="top"
| y_key
| Used to verify ownership for Yahoo! Site Explorer
| [http://help.yahoo.com/l/us/yahoo/search/siteexplorer/siteexplorer-06.html Yahoo! documentation]
|
| Proposal

|-valign="top"
| yandex-verification
| Used to verify ownership for Yandex Webmaster.
| [http://help.yandex.ru/webmaster/?id=995300#995356 Yandex Webmaster ownership verification]
|
| Proposal

|-valign="top"
| globrix.instruction
| Globrix property information: Property to Buy or Rent
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.price
| Globrix property information: Price for the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.postcode
| Globrix property information: Postcode of the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.bedrooms
| Globrix property information: Number of bedrooms the property has
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.bathrooms
| Globrix property information: Number of bathrooms the property has
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.type
| Globrix property information: Type of property e.g. 'semi-detatched house'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.condition
| Globrix property information: Condition of the property e.g. 'renovated'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.features
| Globrix property information: Features of the property e.g. 'double glazing'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.outsidespace
| Globrix property information: External features of the property e.g. 'garden'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.parking
| Globrix property information: Parking available for property e.g. 'parking for 2 cars'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.period
| Globrix property information: Period of the property e.g. 'victorian terrace'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.poa
| Globrix property information: If the property price is only available on application
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.tenure
| Globrix property information: The tenure of the property e.g. 'leasehold'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.underoffer
| Globrix property information: Indicates if the property is under offer
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.priceproximity
| Globrix property information: The region of the attached price e.g. 'guide price of'
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.latitude
| Globrix property information: The latitude of the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| globrix.longitude
| Globrix property information: The longitude of the property
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]
|
| Proposal

|-valign="top"
| meta_date
| The date used to indicate that the Metadata has been prepared and/or reviewed and approved by the Metadata Unit. Its purpose is administrative. (Used by "Autonomy".)
| [http://www.hc-sc.gc.ca/home-accueil/alt_formats/pacrb-dgapcr/pdf/Metadata_Application_Profile_2009.pdf Health Canada Web Metadata Application Profile March 2009 ]
|
| Proposal

|-valign="top"
| Site-Type
| Used to define the body of the document content type offered
| [http://programadorweb.net.tc/?page_id=124 Information and values ??accepted by Metatag]
|
| Proposal

|-valign="top"
| wot-verification
| Used to verify ownership of WOT (Web Of Trust)
| [http://www.mywot.com/wiki/Verify_your_website WOT's verify your site wiki page]
|
| Proposal

|-valign="top"
| gwt:property
| Used to specify the locale client property
| [https://developers.google.com/web-toolkit/doc/latest/DevGuideI18nLocale Locales in GWT]
|
| Proposal

|-valign="top"
| mobile-agent
| Specifies the mobile-compatible url of the web page. Used by mobile browsers and search engines to redirect mobile phone visitors to the proper mobile page. <br>
The following properties can be used in the value of the content attribute:<br>url - The mobile-compatible url of the web page.<br>format - The format of the mobile page. An enum of "wml", "xhtml" and "html5".<br>Example:
<meta name="mobile-agent" content="format=html5; url=http://3g.sina.com.cn/">
| [http://open.shouji.baidu.com/?page=developer&action=pcandmo Baidu Mobile SEO]
|
| Proposal

|-valign="top"
| twitter:card
| The card type, which will be one of "summary", "photo", or "player".
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:domain
| the domain of the website (added w/ API 1.1)
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:url
| Canonical URL of the card content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:title
| The title of the content as it should appear in the card.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:description
| A description of the content in a maximum of 200 characters.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image
| A URL to the image representing the content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image:width
| The width of the image representing the content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image:height
| The height of the image representing the content.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image0
| A URL to the image representing the first photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image1
| A URL to the image representing the second photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image2
| A URL to the image representing the third photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:image3
| A URL to the image representing the fourth photo in your gallery.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:site
| @username for the website used in the card footer.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:site:id
| Twitter ID for the website used in the card footer.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:creator
| @username for the content creator / author.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| twitter:creator:id
| Twitter ID for the content creator / author.
| [https://dev.twitter.com/docs/cards Twitter cards documentation]
|
| Proposal

|-valign="top"
| typemetal.formatprefs
| Per-file HTML formatting preferences used by the TypeMetal HTML editor
| [http://coherencelabs.com/typemetal/manual/typemetal-custom-metadata.html TypeMetal User Guide]
|
| Proposal

|-valign="top"
| vfb-version
| Specifies a Visual Form Builder plugin version for Wordpress.
| [http://wordpress.org/plugins/visual-form-builder/ Visual Form Builder Documentation and specs]
|
| Proposal

|-valign="top"
| wot-verification
| Used to verify ownership of WOT (My Web of Trust).
| [http://www.mywot.com/en/faq/site-owners-support/ownership-verification#why-verify]
|
| Proposal

|-valign="top"
| web_author
| Credits the developer(s) responsible for the technical design of a website.
| [http://www.metatags.info/meta_name_webauthor Documentation]
| [https://sites.google.com/site/metadesignerspec/ designer] - for visual presentation
| Proposal

|-valign="top"
| ZOOMCATEGORY
| Category of page to be grouped in Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMDESCRIPTION
| Alternative page description for Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMIMAGE
| URL to image to be displayed alongside result in Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMPAGEBOOST
| Page boost factor to increase or decrease the relevance of page in Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMTITLE
| Alternative page title for Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| ZOOMWORDS
| Additional keywords to be indexed for Wrensoft Zoom Search Engine.
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]
|
| Proposal

|-valign="top"
| revision
| The revision of this page as reported by an underlying Version Control System. This is a free format string.
| [https://github.com/krallin/meta-revision Meta Revision Specification]
|
| Proposal
|}

== Proposals that don't meet the [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names requirements] for a registration ==

Note that these proposals can be moved back to the registry table if the problems listed in the rightmost column of this table are addressed.

{| class="wikitable sortable"
! Keyword
! Brief description
! Link to specification
! Synonyms
! Status
! Registration requirement failure

|-valign="top"
| gm-gpx-v
| Wordpress Plugin Google Maps GPX Viewer
| [http://wordpress.org/extend/plugins/google-maps-gpx-viewer/ Google Maps GPX Viewer]
|
| Incomplete proposal
| Claimed spec link is not a link to a spec

|-valign="top"
| og:title
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:type
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:url
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:image
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:site_name
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| fb:admins
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| og:description
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| fb:page_id
| Open Graph Protocol by Facebook developers
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]
|
| Incomplete proposal
| The spec specifies this to be a value of the property attribute--not a meta keyword

|-valign="top"
| audience
| To aid search engines in classifying and to aid directory compilers, an audience most appropriate for the page may be suggested. Subject matter may not be a good clue; for example, an analysis of children's literature may be directed to teachers.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated. Singular and plural forms have the same meaning.<br />Recognized values:<br />-- "all" and "everyone", which have the same meaning<br />-- "adult" and "mature" have the same meaning and are for content that only adults may access, but no one responsible for preventing a nonadult or the immature from accessing the page or its content should rely on either or both of these values to do so without other means (not the same as "grownup", which see)<br />-- "child" and "juvenile", which have the same meaning<br />-- "teen"<br />-- "grownup" is not identical to "adult" or "mature" in not implying a precise boundary but is approximately any person who may be able to understand and apply the content (e.g., car driving instruction that may be read by a minor not yet old enough to drive a car but who would likely benefit from somewhat early exposure to the instruction)<br />-- "parent" to include guardian and temporary caregiver<br />-- "teacher" to include professor and ad hoc instructor<br />-- "elementary school student" to include any student below high school<br />-- "high school student"<br />-- "elhi" to include any student in elementary school through high school<br />-- "college student" including graduate and professional school<br />-- "business" including management, finance, and prospective customers (this includes e-commerce and investor sites)<br />-- "health" including any health care provider including alternative and ad hoc<br />-- "patient" for any health care recipient<br />-- "lawyer" including judge, paralegal, and jailhouse lawyer<br />-- "law client" for any prospective recipient of a lawyer's service (not usually a social work client) with ''lawyer'' including paralegal and jailhouse lawyer but not necessarily judge<br />-- "craft" for any craftworker including laborer and artisan<br />-- "artist" including musician, actor, dancer, and sculptor and including creator and performer<br />-- "military" including paramilitary<br />-- "news" including any consumer of rapidly-developing news<br />-- "introductory" and "beginner", which have the same meaning<br />-- "intermediate" and "midlevel", which have the same meaning<br />-- "advanced" and "advance", which have the same meaning<br />-- "scholarly" and "scholar", which have the same meaning<br />-- "popular" generally referring to a writing style<br />-- "older" including retiree<br />-- "institution" including from corporation to conspiracy (such as for management advice)<br />-- "government" including agencies and prospective politicians<br />-- values using any integer or single-digit decimal in the form of "grade 8" or "grade 6.4" including to refer to a reading comprehension level (this generally will not exceed 12 and might be meaningless above 20 so higher values may be interpreted as the highest meaningful value)<br />-- "viewers" for when content (such as a movie) is intended almost entirely to be seen rather than read<br />-- "listeners" for when content (such as music) is intended almost entirely to be heard rather than read but not generally including text-to-speech support<br />-- "tts", "text-to-speech", or "text to speech", which three have the same meaning and which are for a page that has substantial support for TTS or that will be readily understood through TTS without need for such support (TTS is often aided by, e.g., pre-resolving pronunciation ambiguities in page coding)<br />-- values using any numbers in the form of "3-6 years old", whether a range or a single-number value<br />-- values using any decade in the form of "born in 1970s"<br />Unrecognized values such as "botanists", "Texans", and "writers who use red ink" may be used but at a risk that a search engine or directory editor will either fail to recognize it or will interpret it in unpredictable ways, or will in the future.<br />Spellings that are erroneous or slightly different from a recognized value may be interpreted by a search engine or directory editor as representing a recognized value.<br />The absence of the keyword defaults to a value of "all" but without overriding another indication arrived at by other means.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| blogcatalog
| Used to verify ownership of Blog Catalog.com
| [http://www.blogcatalog.com/ Blog catalog site]
|
| Incomplete proposal
| Claimed spec link is not a link to a spec

|-valign="top"
| bot-. . .
| Robot owners, to allow page authors access to robotic capabilities, e.g., to deny them, should prefix "bot-" to the name of their robot, especially for proprietary bots.<br />Example: If a robot were to be named "dullbucklequiz", the name in the meta element would be "bot-dullbucklequiz".<br />The value "bot-" alone represents all bots so prefixed, like a wildcard.<br />Arguably, there's no need for a list here of any specific bots if http://user-agents.org or http://www.botsvsbrowsers.com/ (and perhaps other sites) is reliable.
|
|
| Incomplete proposal
| Lacks link to a spec, tries to register a space of names instead of enumerated names

|-valign="top"
| created
| The datetime at which the document was created. The value is an ISO8601 date. The date MUST follow the [http://www.w3.org/TR/NOTE-datetime W3C Profile of ISO 8601] with a granularity of "Complete date:" or finer. The [http://www.bbc.co.uk/guidelines/futuremedia/desed/previousversions/searchmetadata_vs_1_0.shtml#metadata BBC] use this name.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| creator
| The creator is an off-Web or pre-Web creator of a work for which an author authored a Web page, so that the creator and the author may be different people.<br />Searching for one content creator's work requires a standard robot-parsable format for the information. A personal name, institutional name, or other text entry is permissible.<br />One element represents only one creator. Multiple creators are to be represented with multiple tags.<br />Search engines may index by any component of a name, so a content creator need only enter a name once in one first-last or family-given order (e.g., Pat Thunderbird or Thunderbird, Pat, but not requiring both).
| [[Talk:MetaExtensions#Re:_Proposed_'creator'_MetaExtension|Talk]]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| msnbot
| Synonym of <code>robots</code> for targeting Bing only.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| ia_archive
| Synonym of <code>robots</code> for targeting Internet Archive and Alexa only.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| datetime-coverage
| The author may be the best expert on which time frame is most relevant to the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers that may focus on the 1800s but mention 1731 and 1912 perhaps unimportantly.<br />The value for this keyword is a date or time -- not a range and not vague, for which other keywords are proposed -- in a format in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, all the values so appearing are determinative. Multiple values are to be expressed with separate meta elements lest the note be revised in the future in a way incompatible with comma-separating a list.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| property="og:*"
| Metadata used by the Open Graph protocol (used by Facebook). Note: currently these are defined as: <meta property="og.*" content="x"/>
| [http://developers.facebook.com/docs/opengraph/ FAQ About the Open Graph protocol from Facebook.]
|
| Doesn't belong in this registry
| Not a value to be used in the <code>name</code> attribute

|-valign="top"
| datetime-coverage-end
| This is identical to the keyword datetime-coverage except that it represents only the end. If this keyword is used without datetime-coverage-start (also proposed), its value is interpreted as ending a range without a start.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the end of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-end=1865, datetime-coverage-start=1914, datetime-coverage-end=1918, and datetime-coverage-start=1862, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| datetime-coverage-start
| This is identical to the keyword datetime-coverage except that it represents only the start. If this keyword is used without datetime-coverage-end (also proposed), its value is interpreted as starting a range without an end.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the start of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-start=1862, datetime-coverage-start=1914, datetime-coverage-end=1865, and datetime-coverage-end=1918, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| datetime-coverage-vague
| This is identical to the keyword datetime-coverage except that its value is not necessarily crisp. This keyword should be used only when datetime-coverage, datetime-coverage-start, and datetime-coverage-end are inappropriate, but there's no ban on using all four. Any text without a comma can be the value (e.g., Pleistocene, 1820s, Tuesdays, or before we were born); multiple values are comma-separated.<br />If this keyword is used with datetime-coverage, datetime-coverage-start, or datetime-coverage-end, the vague value should be exploited along with the value/s for the other keyword/s.<br />Should this keyword appear more than once, all are determinative.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| DC.
| Dublin Core, maintained by Dublin Core MetaData Initiative (DCMI), is an extensive system with some overlap with non-DC names.<br />This reserves all strings that begin with DC and a dot. ''Not true; DC-HTML doesn't use hardwired prefixes, but defines the prefixes using link/@rel="scheme.prefix"''
| [http://www.DublinCore.org DCMI]
|
| Incomplete proposal
| Tries to register a space of names instead of enumerated names

|-valign="top"
| dir-content-pointer
| When several pages in a directory include main content, a table of contents, an index, and the like, a search engine may be able to organize results more usefully by identifying which is which with a standard vocabulary, helpful when different publishers use different conventions when displaying or printing content.<br />A value is free-form case-insensitive text without a comma and optionally with a trailing number. Multiple values are to be comma-separated (multiple values are appropriate when one document serves multiple purposes). Singular and plural forms have the same meaning.<br />Recognized values, which are pointer types to which numbers may be suffixed, are limited to "start" meaning 'the first page that should be seen by a user' (this may be anywhere in the directory and anywhere within content), "toc" meaning 'table of contents', "intro" including introductions, forewords, prefaces, and tables of figures, "abstract", "main", "bibliography" and "biblio", which have the same meaning, "index" which may mean 'sitemap' or not, "afterword" and "update" which have the same meaning and need not actually update, "credit" meaning 'credits and acknowledgments', and "author bio" meaning 'author's biography', including any information about the author including credentials and contact information. The number suffix may be spaceless or not.<br />When numbers are suffixed, a search engine or directory should arrange like items in numerical order in the results, with unnumbered items following like items that are numbered, e.g., intro 1, intro 2, main 1, main 2, main, main, and so on.<br />Each directory and each subdirectory has its own sequence.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
|expires
|<code>meta name='expires'</code> defines the expiration date of the page. This can be used for web pages in preparation for an upcoming event, e.g. a registration form for an exposition or competition, or other cases with a pre-set date when the document will no longer be valid, e.g. a product offer in a special sale or a support page for a product known not to be supported anymore from a given time onward.

Search engines should respond to this meta tag in a reasonable way, i.e. by removing the page from their main search results after the expiration date (possibly still returning the result in a special search for expired pages as long as the page exists and is not explicitly excluded via <code>robots.txt</code> or <code>meta name='robots'</code> etc.) or simply by indicating to the user that this result is out-of-date.

The content attribute should define the expiration date in accordance with http://www.w3.org/TR/NOTE-datetime . The meta tag should not be used for pages without expiration date. However, for historical reasons, search engines should also interpret other date formats where possible and should be prepared to find values such as "", "0", "no" and "never". Such non-date values are to be interpreted as no expiration date.

Correctly formatted example:
<code><pre><meta name='expires' content='2012-12-31T23:59Z'></pre></code>

This tag is not to be confused with and has a different meaning than <code>meta http-equiv='expires'.</code>
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| format-print
| This is to allow a user agent to inform an operating system or a printer driver of the preferred print medium, such as the paper size.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated (multiple values might be appropriate because standard paper sizes vary around the world). Singular and plural forms have the same meaning.<br />Recognized values are limited to "letter", "A4", "legal", "A5", "B5", "monarch", "envelope 10" meaning size #10, "envelope 6-3-4" meaning size #6 3/4, values with integers and decimals in the form of "8.5 x 11" or "8.5x11" in which spacing of the "x" does not affect meaning, "paper", which means 'paper of the default color (usually white) and weight (usually 20-lb. stock)', "white", "yellow", "pink", "blue", "green", "violet", or "multicolor", which means a medium of the given color or mixed, "letterhead", "p2 letterhead" meaning 'letterhead intended for any page except the first', "watermark" meaning a 'special watermark such as an organization's own', and "plain" meaning 'not preprinted and not letterhead (it may have a paper manufacturer's watermark not related to letterhead)'.<br />Omitting "paper" when another recognized value is given defaults to an implied meaning of 'paper' with the other value; e.g., "letter" means 'letter paper'; the same principle applies to a medium's color (the default being white for paper and colorless for transparency) and plainness or lack thereof (the default being plain).<br />Other values should be proposed before being recognized here. Label sizes should be proposed here for labels that are not on backing sheets that fit one of the recognized values, e.g., labels on narrow rolls. Blueprint paper sizes should be proposed here. Media other than standard paper, such as onion skin, heavier paper, card, and clear or color transparency, should be proposed here.<br />The user agent may, with the user's or user sysadmin's permission (as by a menu-driven default), interpret a value to offer an alternative the user might accept and software and firmware other than the UA may interpret a value to the same end with or without permission, so this keyword is only suggestive; e.g., "letter" may be interpreted as "A4".<br />The absence of the keyword defaults to a value determined by other than the page, e.g., by the printer driver or the user agent.
| [[Talk:MetaExtensions#Re:_Proposed_'format-print'_MetaExtension|Talk]]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| geographic-coverage
| The author may be the best expert on the geographic relevance of the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers and epidemiological studies which may mention locales only once.<br />Absence of the keyword defaults to a value of world (not universe), unless the search engine chooses to interpret the page or larger unit for some other value, probably based on other than just contact information given in the website.<br />The value for this keyword is a semicolon-separated list of one or more place-values, the order of which do not matter. One place-value will use commas to separate, in order, an optional standard natural language symbol applicable to the place-value (when omitted the language applicable to the page will control), a place-class, one or more place-subclasses if any, and one or more place name parts (where, e.g., in "Cape Town, South Africa", "Cape Town" is a place name part but "Town" is not). Spaces after semicolons and commas are optional; spaces within place-values are present when required for each place-value (e.g., "Quezon City", not an invented "QuezonCity").<br />To distinguish names that might otherwise be too similar, place-classes, all lower-case and hyphenatably spaceless, include ''outer-space'', ''region'' (on Earth and crossing or larger than a nation, e.g., southern hemisphere, polar region, temperate zone, or Asia), ''intntl-water'' (an 'international water body'), ''intntl-agcy'' ('international agency' or 'international collection', e.g., all U.N. member nations), ''nation'', ''within-nation'' (limited to only one political level down from nation, e.g., state, province, territory, possession, city not included within other political units of a nation, or any comparable unit), ''city'' (including town, village, hamlet, and any comparable political unit below the level of ''within-nation''), ''addr'' (including address, full-length street, building, institution, and neighborhood without political boundaries), ''pol-unit'' (''pol'' abbreviating 'political') (e.g., a place of disputed nationhood), ''hist-pol-unit'' (''hist'' abbreviating 'historical') (e.g., the Roman Empire), ''feature'' (e.g., river), ''num'' (e.g., latitude and longitude or outer-space equivalent in numbers), and ''ethereal'' (including thealogical/theological, fictional including from modern popular entertainment, and ancient secular mythical, but not including that which is asserted to be a state of mind or existence but not a place, such as nirvana). (Example for one hypothetical page: name="geographic-coverage" content="region, sub-Saharan Africa; nation, Panama; city, Panama, Panama; within-nation, Sao Paulo, Brazil; city, Sao Paulo, Sao Paulo, Brazil; within-nation, Mississippi, United States of America; region, Middle East; region, Midwest, United States of America; hist-pol-unit, Northwest Territory, United States of America; feature, river, Indus; outer-space, Indus; ethereal, ultima Thule; ethereal, Heaven; ethereal, Flatland; ethereal, Valhalla; en-US, addr, Hotel Valhalla, Fredrikstad, Norway; es, nation, Espana" (Indus is both a river and a constellation, illustrating the need for place-classes)).<br />Ambiguity of place-values should be avoided despite convenience in coding because search engines may each interpret them as they see fit, e.g., it would be hard for an engine to distinguish New York from New York.<br />For consistency of spelling, several authority lists should be settled upon, with legal, well-known, and disputed names and common abbreviations all being acceptable; but I'm not proposing one here now (relying on IANA's ccTLD list might be too complex to implement and still assure coding consistency, e.g., occasionally ccTLDs can be phased out and off of IANA's list) (a standard vocabulary possibly usable here is the [http://www.getty.edu/research/conducting_research/vocabularies/tgn/index.html Getty Thesaurus of Geographic Names Online], subject to licensing and charset choice); and promulgating authority lists may best be done publicly by search engine managements, who may disagree with each other.<br />Allowing Unicode for non-Roman alphabet-using locales is desirable, but at present that may raise technical problems, including computer security issues, that are not yet readily soluble.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| keywords-not
| A comma-separated list of negative keywords that distinguish a closely-related theme from this page's true theme, to support Boolean NOT searches often more realistically than visible text can, especially when both themes share the same lexicon.<br />If keywords is no longer a supported name for a meta element, keywords-not is superfluous; however, debate has been revived on whether keywords should be supported or not; see the keywords entry in this Wiki.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6609 W3C Bug 6609]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| nextgen
| Used for nextgen gallery plugin in wordpress
| [http://www.alexa.com/faqs/?p=188 Alexa FAQ About this meta attribute Reference]
|
| Incomplete proposal
| Unrelated spec link

|-valign="top"
| page-datetime
| Better ranking in search engine results for recency or relevance to an event date would be aided by a standard format robots can parse. Users would save search time by not having to load many pages to find which ones are new or date-relevant.<br />To supply a consistent and known format, the value for this keyword is a date-time expression formed in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, only the first one so appearing is determinative.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| page-version
| Pages may be revised several times daily. While date-time given to a granularity of a fraction of a second would often suffice, when a page has to be approved more than once before posting, any or no such time may be correct (without this keyword, a comment could be necessary but probably not parsable by an engine). In addition, versions regardless of date may show consecutiveness and can replace a date that must be vague. In that case, a version number may be more useful for searches and so a robot-parsable format is needed.<br />The keyword's value is stated in ASCII digits, is any nonnegative base-10 rational number expressed as an integer or a decimal, with any number of decimal places allowed, and may be padded with any number of leading zeros to support extraction for ASCII sorting.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />The versions 0 and 0.''n'', with ''n'' being to any number of places, signify beta versions, i.e., drafts, in the tradition of beta software, while versions 1 and higher ordinarily signify final-release versions. After a final-release version is released, a draft of a later version is not given a version number of 0 or 0.''n'', but is numbered higher than the last final-release version. It is suggested to page authors that draft status, if applicable, be shown in the visibly displayed text of the page, rather than that this meta tag be relied upon as the sole notice of draft status, as it may be inadequate notice if alone.<br />To assign a low page-version such as 0.''n'' or 1, the page's URL, if static, may be used as the relevant premise. Thus, if a page is copied or moved to a new URL, the author may choose to restart page-version numbering from 0.''n'' or 1. If a page's URL is dynamic, e.g., if created on the fly from a script, the page author may prefer to use as the relevant premise for assigning a low page-version such as 0.''n'' or 1 the URL of the script or other technology that generates the dynamic-URL page, placing this meta element containing this attribute within the script or other technology, not within the generating page's head element (the generating page's head element may have its own meta element with this attribute describing the generating page). If one page containing the script or other technology that generates another page has more than one means for generating dynamic-URL pages, each means should contain its own meta element with this attribute. Page-version is thus largely independent of the page's date, although both would likely advance roughly in parallel.
|
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| resolutions
| Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.

To accomplish this, I propose a new HTML Meta Tag, <code>resolutions</code>, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page.

So, for example…

<code><pre><meta name="resolutions" content="2x"></pre></code>

… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix.

To illustrate, if her image tag is as follows…

<code><pre><img src="/images/flower.jpg" alt="A flower"></pre></code>

… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg.

(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)

Based on the meta tag, if the browser detects that the user is running at a <code>min-device-pixel-ratio</code> of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag.

Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.

<b>Multiple resolutions</b>

The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future.

For example:

<code><pre><meta name="resolutions" content="2x, 4x, 8x"></pre></code>

In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.

<b>Advantages</b>

The advantages of this approach are several:

<ol>
<li>Makes it very simple for developers to support high-resolution displays like the iPhone 4's Retina screen</li>
<li>Does not require JavaScript</li>
<li>Does not change the default way that things work (if the meta tag is not specified, the browser simply behaves as it always has).</li>
</ol>

| [http://aralbalkan.com/3355 Proposal for native browser support of high-resolution image substitution]
[http://aralbalkan.com/3331 How to make your web content look stunning on the iPhone 4’s new Retina display]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| rights
| As a page effectively appears in at least two forms, usually one as interpreted and displayed on a device and the other as source code, arguably intellectual property rights that must be asserted must be asserted in ways understandable in both contexts. For example, &copy; is a raw representation that may legally fail as part of copyright notice to someone seeing source code and not the display, important when someone wants to copy source code for use elsewhere and may rely on a defense of innocent infringement (at least in U.S.). While such assertions can be made in a comment element, it may be helpful to have a tag that search engines can parse and index verbatim.<br />The value may include standard and nonstandard notices, invocations of licenses such as GFDL and ASCAP, and any other information. Content is defined as free-form, leaving the page author discretion for the entry.<br />Statements in one tag may discuss several portions of the page differently, e.g., with different licenses.<br />More than one license may be offered, along with the page's relationship to all.<br />Not all statements need be license grants. A statement may state whom to ask for reprint permission or may reserve all rights, for example.<br />Only one meta tag with this keyword may be present. Page authors must not use more than one. A UA finding multiple such tags on one page must ignore all of them.<br />The copyright symbol that would be generated by its character entity is not recommended for legal notice in source code when the word 'Copyright' may be used instead, because the entity may be read in raw form, but use is up to the page author. The same concept applies to any intellectual property rights symbol for which a suitable alternative is available, such as for trademark or service mark.<br />ASCII text would not suffice when a name or notice legally may have to be in a non-Roman alphabet, but no alternative may yet exist in HTML5.<br />Search engine storage may impose a length limit, but, because of legal consequences, if the value's length exceeds a given limit the search index should retain or interpret none of it but only refer to it.<br />The content string may only be copied verbatim in its full length, referred to, or ignored. It may not be, for example, paraphrased, truncated, interpreted, or classified except in addition to being copied verbatim in its full length.<br />Ignoring shall not void, nullify, or alter any rights stated in such tag.<br />For the synonymy, ''IP'', ''IP-rights'', and ''IP-right'' are not reserved; while the abbreviation ''IP'' 'intellectual property' is common among attorneys in the U.S., page authors will more likely be computerate, and the abbreviation may be wanted for 'Internet Protocol'.
| [[Talk:MetaExtensions#rights:_why_reversion|Talk]]
|
| Incomplete proposal
| Lacks link to a spec

|-valign="top"
| subj-. . .
| To classify by subject a page's content, a standard subject taxonomy that will be recognized by a search engine or directory will help. Because many such high-quality taxonomies exist, only a prefix is proposed. Over time, particular taxonomies, in print or online, may be recognized here and keywords assigned for each.<br />The keyword will be constructed case-insensitively with subkeywords in the form subj-[nationAbbrev]-[taxonomy]-[edition][-optionalSubedition], e.g., subj-US-MeSH-2009online (perhaps). After "subj-", the second subkeyword will identify the nation where the taxonomy is published or offered as an aid in identifying the taxonomy and does not limit the subject coverage; e.g., a taxonomy published in Japan may be ideal for classifying Canadian botany or Peruvian economy.<br />As subject values may vary between editions of one taxonomy, an edition and optionally a subedition is to be identified in the third and optionally the fourth subkeywords. The subedition, if any, is any update or revision occurring between editions, such that a value drawn from that edition and subedition is stable. The means of identifying edition and subedition should be included in the registration of a keyword.<br />Examples of taxonomies from the U.S. include MeSH (medical) and the Library of Congress Subject Headings.<br />The value identifying a subject for a Web page will be drawn from the cited taxonomy's edition and subedition.<br />If the value should have a style to prevent ambiguity in interpretation, that style is to be registered here for that keyword. Multiple values are expressed with multiple meta elements, one value for each, since comma-separation is probably not compatible with all taxonomies.<br />If a value requires case-sensitivity to prevent confusion, the entry here registering the keyword must accommodate that need with the needs of HTML 5 with an appropriate rule. To that end, a proposal to allow case-sensitivity in meta tags under some circumstances has been offered in the W3C bug reporting system.
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854 W3C Bug 6854]
| subject-. . .
| Incomplete proposal
| Lacks link to a spec, tries to register a space of names instead of enumerated names

|-valign="top"
| nibbler-site-verification
| Used to verify ownership of Nibbler site
| [http://nibbler.silktide.com/ Nibbler site]
|
| Incomplete proposal
| Claimed spec link does not link to a spec

|-valign="top"
| MSSmartTagsPreventParsing
| Microsoft introduced into Internet Explorer 6 Beta a feature that some website designers wished to preclude from applying in order to prevent public misunderstanding of their websites. The feature allowed a browser to add information but at a risk that users wouldn't know that it wasn't supplied by the website. This keyword was provided by Microsoft for those of us who wanted it.<br />Its value was "TRUE". Microsoft spelled the keyword with some capitals and the value in all capitals but whether capitalization was required for either is unknown; some opinions vary. Since it need be understood by only one browser, and that one a beta version, full standards compliance should not be assumed, and original case may be required. (This tag is used by Google: "<meta content='true' name='MSSmartTagsPreventParsing'/>" appeared (with internal quote marks as singles) in the source code for <http://googleblog.blogspot.com/2009/04/listening-to-google-health-users.html>, as accessed 4-27-09.)<br />Microsoft has apparently removed this instruction from its website on the ground that the beta version is no longer available and is not supported, but that doesn't assure that some users aren't still using the beta browser, perhaps inadvertently. Therefore, designers may wish to continue using the keyword and value and they are preserved here.
| e.g., [http://www.theregister.co.uk/2001/06/25/web_sites_banish_those_winxp/ The Register (U.K.)], [http://cc.uoregon.edu/cnews/summer2001/summer2001.pdf Univ. Oregon (U.S.) (PDF p. 18)], & [http://trillian.mit.edu/~jc/demo/SmartTagsOff.html John Chambers (U.S.) (job résumé near root)], all as accessed 4-19-09
|
| Incomplete proposal
| Lacks spec, potentially never minted by MS as a meta name (as opposed to a http-equiv value), even if minted by Microsoft, abandoned before shipping in any final release of IE

|}

== Failed Proposals ==

{| class="wikitable sortable"
! Keyword
! Brief description
! Link to more details
! Synonyms
! Status

|-valign="top"
| cache
| This doesn't actually work; use HTTP headers instead.<br />Value must be "public", "private", or "no-cache". Intended as a simple way to tell user agents whether to store a copy of the document or not. An alternate for HTTP/1.1's cache-control; for publishers without access to modifying cache-control.
| none
|
| Unendorsed

|-valign="top"
| no-email-collection
| HTML5 prohibits URL-valued meta names. They should be rel keywords instead.<br />Intended to reference legal policy of web site indicating that harvesting of e-mail addresses on the site is not permitted and in violation of applicable laws such as the CAN-SPAM Act of 2003.
| [https://www.ProjectHoneyPot.org/how_to_avoid_spambots_5.php Project Honey Pot]
|
| Unendorsed

|}

== Process ==

For the "Status" section to be changed to "Ratified", the proposed keyword must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Unendorsed".

For more details, see [http://whatwg.org/specs/web-apps/current-work/#concept-meta-extensions the HTML5 specification].

[[Category:Registries]]

Rel

2013-11-16T20:53:47Z

Tantek: draft with link to official rel registry

{{stub}}

You may be looking for the official rel registry which can be found here:

* http://microformats.org/wiki/existing-rel-values

In particular if you have a new rel value to propose or add to HTML, see:
* http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types]

Anolis

2013-04-25T19:35:36Z

Tantek: add workaround for TypeError Item in from list not a string

Anolis is a tool to generate specification-like documents out of simple HTML.

* http://pimpmyspec.net/
* http://hg.hoppipolla.co.uk/ -- jgraham's work
* http://bitbucket.org/ms2ger/anolis -- used by most WHATWG standards, the latest version

== Setting up ms2ger/anolis ==

* Install http://bitbucket.org/ms2ger/anolis:
hg clone http://bitbucket.org/ms2ger/anolis
cd anolis && sudo python setup.py install
* install lxml using whatever package manager is appropriate for your OS/environment; for example, one of the following:
sudo easy_install lxml
sudo port install py27-lxml
sudo apt-get install python-lxml
* install cssselect using whatever package manager is appropriate for your OS/environment; for example, one of the following:
sudo easy_install cssselect
sudo port install py27-cssselect
sudo apt-get install python-cssselect
* install html5lib:
hg clone https://code.google.com/p/html5lib
cd html5lib/python && sudo python setup.py install

== Troubleshooting ==

=== No targets specified ===
If you try to "make" and get a message like:<pre>make: *** No targets specified and no makefile found. Stop.</pre>
Then you're likely trying to do a <kbd>make</kbd> in the wrong directory.

Solution:
# Change your current directory to the parent of the item you're trying to make,
# Verify that there is a "Makefile" in that directory,
# Try again

=== No rule to make xref ===
If you try to "make" and get a message like:<pre>make: *** No rule to make target `../xref', needed by `Overview.html'. Stop.</pre>
Then you're likely missing the "xref" repository.

Solution:
# Clone the "xref" repository into a directory that is a sibling of the directory you're working in.
# Try again

=== No such option xref ===
If you try to "make" and get a message like:<pre>anolis: error: no such option: --xref</pre>
Then your Anolis is likely out of date.

Solution:
# Update your Anolis respository
# Update your install of the "anolis" tool, e.g. in "/usr/local/bin/anolis"
# Try again

=== No module named lxml ===
If you try to "make" and get a message like:<pre>ImportError: No module named lxml</pre>
Then you're missing the lxml library.

Solution:
# Install lxml per the above instructions, e.g. <kbd><pre> sudo easy_install lxml</pre></kbd>
# Try again

=== Connection reset by peer ===
If you're trying to install lxml and get an error message like:
<pre>Downloading http://lxml.de/files/lxml-3.1.2.tgz
error: Connection reset by peer</pre>
Then the network you're on may be problematic.

Solution:
# Switch to a different network (e.g. a mifi)
# Try again

=== TypeError Item in from list not a string ===
If you try to "make" and get messages like:
<pre>
Traceback (most recent call last):
File "/usr/local/bin/anolis", line 325, in <module>
main()
File "/usr/local/bin/anolis", line 69, in main
tree = generator.fromFile(input, **kwargs)
File "/Library/Python/2.7/site-packages/anolislib/generator.py", line 90, in fromFile
process(tree, processes, **kwargs)
File "/Library/Python/2.7/site-packages/anolislib/generator.py", line 38, in process
locals(), [process], -1),
TypeError: Item in ``from list'' not a string
make: *** [Overview.html] Error 1
</pre>
Then ... (no idea)

Solution:
* TBD

Workaround:
# Give up on locally installed Anolis
# Commit your Overview.src.html as is, noting in the commit message that the Overview.html was not updated
# Use the http://anolis.hoppipolla.co.uk/aquarium.py web service
# Submit the raw.github.com "raw file" URL of the Overview.src.html you just committed
# Save the result over the Overview.html in the same directory as the Overview.src.html
# Commit it with message "sync with Overview.src.html - used anolis.hoppipolla.co.uk/aquarium.py"

[[Category:Spec coordination]]

Anolis

2013-04-25T19:19:08Z

Tantek: document where I got stuck with Anolis

Anolis

2013-04-25T19:02:41Z

Tantek: more troubleshooting: No module named lxml, Connection reset by peer

Anolis

2013-04-25T18:37:38Z

Tantek: add troubleshooting section with actual problems/errors encountered and solutions that worked

Time element accepted

2013-02-25T12:47:36Z

Tantek: impedance match new date time inputs was accepted, year week only updated to keep a request for more examples

Time element

2013-02-25T12:41:58Z

Tantek: impedance match new date time inputs was accepted (copy/moved accordingly), scoped remaining inputs to impedance match new time granularity proposal

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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.

The time element has been improved through the research done on this page. See:
* [[Time element accepted|Time element: accepted proposals]]

Please read the following proposals for improving the <time> element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

== Date granularity ==
All Date granularity proposals have been accepted. See: [[Time element accepted]].

== HTML5 internal consistency ==
=== impedance match new date time inputs ===
The proposal to impedance match new date time inputs was partially accepted (additional time element granularity). See: [[Time element accepted]].

=== inputs to impedance match new time granularity ===
While this could be documented on an [[input]] element page, it made sense to keep it here as it's a part of time element discussion.

For each time element granularity, there should be a corresponding input element.

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

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (accepted as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (accepted as of 2011-11-18)
<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"> - <time>YYYY</time> (accepted as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (accepted as of 2011-11-18)
</nowiki></pre>

The following [[input]] elements are proposed to represent the respective time element granularity:

* input type="year"
* input type="month-day"

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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-1600"[http://en.wikipedia.org/wiki/Basawan]), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Category:Public domain license

2013-02-20T19:14:34Z

Tantek: l

Please see the new [[:Category:CC0_users]] page, and add this to your user page:

<div style="margin:1em 0"><code style="display:block;background:#EEE;padding:.5em;font-size:larger;font-weight:bold"><nowiki>{{CC0 user}}</nowiki></code></div>

CC0 is an upgrade from CC-public-domain so you should use that instead.

Thanks!

== Previously ==
By adding the public domain license template to your user profile page, you can ensure that your contributions to the whatwg.org community wiki and mailing lists are available as openly as possible. As more users choose to adopt it, much of the wiki's content will become available under clear, free terms.

You can add it to your profile by 1) logging in, 2) clicking on your name at the very top of the web page (the username link on the right side has a little "person"
icon), 3) clicking Edit (or ctrl-E(mac)/alt-E(windows)), 4) pasting the following text into the bottom of your page, and 5) clicking Save (ctrl-S(mac)/alt-S(windows));

<div style="margin:1em 0"><code style="display:block;background:#EEE;padding:.5em;font-size:larger;font-weight:bold"><nowiki>{{cc-public-domain-release}}</nowiki></code></div>

See the [[#articles|list of those that have already done so]].

==Why Public Domain?==
Inspired by Wikipedia and [http://microformats.org/wiki/Category:public_domain_license microformats.org], there's a new template that you can add to your profile to indicate your support for this option, which ensures the broadest possible reuse of your contributions in future discussions, specifications, and in other media such as books.

What difference will this make? If enough contributors eventually support this, entire pages of the wiki will become public-domain works, not just their individual snippets.


<div id="articles"> </div>

Category:Public domain license

2013-02-20T19:14:09Z

Tantek: use CC0 instead

Please see the new [[Category:CC0_users]] page, and add this to your user page:

<div style="margin:1em 0"><code style="display:block;background:#EEE;padding:.5em;font-size:larger;font-weight:bold"><nowiki>{{CC0 user}}</nowiki></code></div>

CC0 is an upgrade from CC-public-domain so you should use that instead.

Thanks!

== Previously ==
By adding the public domain license template to your user profile page, you can ensure that your contributions to the whatwg.org community wiki and mailing lists are available as openly as possible. As more users choose to adopt it, much of the wiki's content will become available under clear, free terms.

You can add it to your profile by 1) logging in, 2) clicking on your name at the very top of the web page (the username link on the right side has a little "person"
icon), 3) clicking Edit (or ctrl-E(mac)/alt-E(windows)), 4) pasting the following text into the bottom of your page, and 5) clicking Save (ctrl-S(mac)/alt-S(windows));

<div style="margin:1em 0"><code style="display:block;background:#EEE;padding:.5em;font-size:larger;font-weight:bold"><nowiki>{{cc-public-domain-release}}</nowiki></code></div>

See the [[#articles|list of those that have already done so]].

==Why Public Domain?==
Inspired by Wikipedia and [http://microformats.org/wiki/Category:public_domain_license microformats.org], there's a new template that you can add to your profile to indicate your support for this option, which ensures the broadest possible reuse of your contributions in future discussions, specifications, and in other media such as books.

What difference will this make? If enough contributors eventually support this, entire pages of the wiki will become public-domain works, not just their individual snippets.


<div id="articles"> </div>

User:Tantek

2013-02-20T18:07:07Z

Tantek: add CC0 release

== hello!==
<div style="float:right">
__TOC__
</div>

<div class="vcard">Hi, I'm <span class="fn">Tantek Çelik</span> and my home page is <span class="url">http://tantek.com/</span>.
<div class="note">
I've been working on and advocating open web standards since 1998, in particular in the W3C CSS and HTML working groups, and have most recently written and published an HTML5 tutorial video/book:

* [http://tantek.com/html5now HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today]

I've also recently given several [[presentations]] on HTML5.

I am a contributor to HTML5, and encourage the web authoring/design/development community to add to the [[Main_Page|WHATWG Wiki]] and send feedback to the [http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org WHATWG list].
</div>
</div>

== CC0 release ==
{{CC0 user}}

== public domain release ==
{{cc-public-domain-release}}

== disclosure ==
I'm currently (as of 2011-176) a Mozilla employee developing and coordinating work on web standards.

Much of this relates to HTML5.

See my [https://wiki.mozilla.org/Tantek-Mozilla-projects list of projects that I'm working on with Mozilla].

== articles created ==
=== elements ===
* [[cite element]]
* [[del element]]
* [[Input element]]
* [[main element]]
* [[summary element]]
=== attributes ===
* [[charset]]
* [[Content-Language]]
* [[Iframe Sandbox]]
* [[Img Alt]]
=== other ===
* [[Getting started with browser development]]
* [[Irc-people]]

=== templates created ===
* [[Template:Cc-public-domain-release]]
* [[Template:For]]
* [[Template:Irc_user]]
* [[Template:Stub]]

=== categories created ===
* [http://wiki.whatwg.org/wiki/Category:Public_domain_license Public domain license]

=== redirect articles created ===
* [[alt]]
* [[cite]]
* [[del]]
* [[Faruk]]
* [[Hixie]]
* [[input]]
* [[irc]]
* [[longdesc]]
* [[main]]
* [[Sandbox]]
* [[summary]]
* [[Tantek]]
* [[time]]

== articles edited ==
See my list of edits: [[Special:Contributions/Tantek]]

=== sections created ===
Created the following sections in existing articles:
* Main_Page
** [[Main_Page#Research_and_data|Research and data]]
* Table_Summary
** [[Table_Summary#Research|Research]]
* Time_Element
** [[Time_Element#year_only|year only]]
** [[Time_Element#year_month_only|year month only]]
** [[Time_Element#month_day_only|month day only]]

== see also ==

Time element

2013-02-15T20:38:30Z

Tantek: start moving accepted proposals to a new page

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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.

The time element has been improved through the research done on this page. See:
* [[Time element accepted|Time element: accepted proposals]]

Please read the following proposals for improving the <time> element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

== Date granularity ==
All Date granularity proposals have been accepted. See: [[Time element accepted]].

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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-1600"[http://en.wikipedia.org/wiki/Basawan]), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element accepted

2013-02-15T20:38:19Z

Tantek: draft with accepted date granularity proposals

Time element

2013-02-15T20:13:58Z

Tantek: /* Fuzzy dates */ changed flourished example to have a end date range and add WP citation

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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-1600"[http://en.wikipedia.org/wiki/Basawan]), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Main element

2012-12-14T00:55:44Z

Tantek: /* Arguments for */ definitively answers a common question

There is an HTML5 extension specification that proposes adding a <code>main</code> element to HTML5.

* https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

Summary: This page contains arguments for, rebuttals to arguments against, and research/data supporting the introduction of a <code>main</code> element to HTML/HTML5.

HTML5 has several new "block like" semantic elements (article, aside, section), including header and footer elements. There is no element to represent (and provide a hook for) for ''the'' "main content". The only landmark ARIA role that lacks an equivalent semantic HTML element is also called "main", and it is being used on real world websites.

This page contains:
* positive reasoning and supporting evidence for <code><main></code>
* arguments against <code><main></code>, with follow-ups
* counter-proposals to <code><main></code>, with explanation of inadequacies

== Use cases ==
Though there are some documentation of use-cases elsewhere, it's helpful to provide some of these in this context to help with consideration of the proposal.

=== Reduce need for explicit skip links ===
One of the motivators was to get rid of skip links (http://webaim.org/techniques/skipnav/).

A main element would reduce work for authors.

Adding skip links is extra work for the author, particularly for accessibility, and thus it can be missed.

It would be less work for authors to simply use a main element. Authors naturally use the semantics of a main content area (with classes, id etc.) thus if they were given a <code>main</code> element to use, they'd easily use that instead (paving a cowpath).

Browsers could (user-configurably) provide some sort of built-in skip to main content gesture (link, or other mechanism).

== Arguments for ==
In general there must be a high burden of justification for adding new elements, in order to keep the language easier and more usable overall. Every new element adds cost to learning/usability, and thus must more than make up for it in benefits.

=== paves a cowpath ===
A <code>main</code> element paves an already researched cowpath.

Or: it should have been included with header footer et al.

The introduction of <code><header></code>, <code><footer></code>, <code><aside></code>, <code><nav></code>, and <code><article></code> is based on careful consideration based on data gathered (in 2005).

Even according to Hixie’s research, the class “content” ranked higher than “nav” or “header”. It would be even more obvious if you took the sum of “content”, “main” and “body” (as class names or ids).

See https://developers.google.com/webmasters/state-of-the-web/2005/charts/top20-classes.svg .

That Hixie left <code><main></code> out in the first place is not justified by the research presented.

=== avoids last case of having to use an ARIA landmark ===
"Use of ARIA (a stop gap) should be a smell. Using it generally
implies a weakness in native semantic, or, an abuse of native semantics." -David Bolter

Additionally, role=main is the most commonly used ARIA landmark per:
* http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/
And it’s the only landmark that doesn’t have a one-to-one mapping to an HTML element name.

A main element would avoid the need to use role="main".

=== definitively answers a common question ===
On various development forums and sites, there are many questions of the nature: what HTML5 element do I use for the main content of my page? E.g.:
* Sitepoint: [http://www.sitepoint.com/forums/showthread.php?855981-Main-content-area-in-HTML5-what-is-correct Main content area in HTML5 - what is correct ????]
* Stack Overflow: [http://stackoverflow.com/questions/12438300/html-5-element-for-content HTML 5 element for content?]

Given that web developers are already asking these questions (and getting wildly inconsistent answers), and that they're going to author *something* for what they consider the main content, a main element would naturally provide this functionality, and alleviate a common source of confusion.

== Arguments against ==
=== Lack of concrete use case documentation ===
See previous [[Main_element#Use_cases|Use cases]] section.

=== main does not meet a high bar of inclusion ===
Per the research cited in [[Main_element#paves_a_cowpath|paves a cowpath]], a main element meets a higher bar than "article" for example (which has plenty of real world use in blog posts), and certainly more than "hgroup" (which is debatable whether it should be kept or not).

== Counter-proposals ==
=== Use existing markup instead ===
==== first article ====
Referred: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037826.html

Summarized:
* To Authors: just use <code><article></code>. The main contents of a page are worthy of independently syndicating - nearly all content on the web works this way today.
* To Accessibility Tools: If you don't find a role=main element, then just use the first <code><article></code> in the page as if it were a <code><main></code> element.

The use of <code><article></code> instead also makes sense as a generalization of <code><main></code> that arises as soon as one thinks of how to write processing rules for the case where a page has more than one <code><main></code> even if it isn’t supposed to have more than one <code><main></code>.

Questions:
* Q: Where's the end of <code><main></code> content?
** A: End of the last <code><article></code>.
* Q: How do you skip stuff between <code><main></code> elements?
** A: Skip stuff between <code><article></code> elements.
* Q: Is it appropriate to use <code><article></code> in the gmail message list?
** A: Yes, each message does have its own URL, and POP could arguably be a form of syndication.

===== problems with first article =====
Problems with the first article rule: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html][https://bugzilla.mozilla.org/show_bug.cgi?id=820508#c3]

1) The generalization no longer looks the way authors think. The
cowpath being paved is hard to recognize. That is, the idea that you
replace <code><div id=content></code> or <code><div id=main></code> with <code><main></code> is more intuitive than that you replace <code><div id=content></code> with <code><article></code> but
you also replace each <code><div class=comment></code> with <code><article></code> and since the comments come after the main article, the first <code><article></code> ends up having the semantics of main content.

2) When role="main" exists, it’s hard to convince people that implicit works as well as explicit. Even if browsers actually exposed the right accessibility API role for first <code><article></code>, authors would still probably feel it’s better to say role="main" just in case. I would love to see ARIA obsoleted in the sense that people who don’t retrofit accessibility to legacy code and who aren’t recreating GUI widgets is JS wouldn’t need to deal with ARIA (where including role=main just in case because one doesn’t trust rules like “first <code><article></code>” counts as “needing” to deal with ARIA).

3) Even though in principle, the element names are just runes whose
meaning is given by the spec—not by the English meaning of the element
name, people still try to guess usage from the element name. It’s
pretty easy to believe from element names alone than <code><main></code> is <code><div id=content></code> or <code><div id=main></code> made as a part of the language itself. It’s harder to grok the defined semantics of <code><article></code> from its element name.

4) It’s more obvious to write main { ... } in CSS than
article:first-of-type { ... }

5) "first article" fails to handle cases like:
<source lang=xml>
<section>
<h1>Heading</h1>
<aside> ... </aside>
<nav> ... </nav>
text...
<aside> ... </aside>
<aside> ... </aside>
text...
</section>
</source>

== Implementation impact ==
Notes on potential implementation impact of a main element on web browsers.

To be done right, <code><main></code> and <code><p></code> should interact the way e.g. <code><article></code> and <code><p></code> do.

Consider
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1939 and
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1940

vs.

* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1942 and
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1941

Implementer feedback:
* Mozilla:
** From a layout engine implementation point of view the burden is trivial.
** The parser change would be absolutely trivial. There is absolutely no basis for opposing <code><main></code> on the grounds of amount of parser change work needed.

== Implementation bugs ==
* Mozilla Firefox/Gecko: [https://bugzilla.mozilla.org/show_bug.cgi?id=820508 Bug 820508 Add support for <main> element]
* WebKit: [https://bugs.webkit.org/show_bug.cgi?id=103172 Bug 103172 - implement the HTML <main> element]

== Open issues ==
=== Different HTML parsing algorithms ===
It’s just unfortunate that if <code><main></code> was introduced, the HTML parsing algorithm wouldn’t be one exact thing but there’d be HTML parsing pre-<code><main></code> and HTML parsing post-<code><main></code> and during the transition, Web authors would have to explicitly write the </p> tag, which is supposed to be optional. However, we are headed to a world where there will be HTML parsing pre-<code><template></code> and HTML parsing post-<code><template></code> anyway.

== Asides ==
=== Mesolithic analogy ===
It's interesting that debates over introducing a term for "the middle part" of something long predate this discussion, see for example the controversy over the introduction of the term "mesolithic":

http://en.wikipedia.org/wiki/Mesolithic#History_of_the_concept

as the thing between, Paleolithic (header), and Neolithic (footer). Despite the controversy, mesolithic is now an established term.

Main element

2012-12-13T21:37:21Z

Tantek: another problem with first article, note Implementation bugs

There is an HTML5 extension specification that proposes adding a <code>main</code> element to HTML5.

* https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

Summary: This page contains arguments for, rebuttals to arguments against, and research/data supporting the introduction of a <code>main</code> element to HTML/HTML5.

HTML5 has several new "block like" semantic elements (article, aside, section), including header and footer elements. There is no element to represent (and provide a hook for) for ''the'' "main content". The only landmark ARIA role that lacks an equivalent semantic HTML element is also called "main", and it is being used on real world websites.

This page contains:
* positive reasoning and supporting evidence for <code><main></code>
* arguments against <code><main></code>, with follow-ups
* counter-proposals to <code><main></code>, with explanation of inadequacies

== Use cases ==
Though there are some documentation of use-cases elsewhere, it's helpful to provide some of these in this context to help with consideration of the proposal.

=== Reduce need for explicit skip links ===
One of the motivators was to get rid of skip links (http://webaim.org/techniques/skipnav/).

A main element would reduce work for authors.

Adding skip links is extra work for the author, particularly for accessibility, and thus it can be missed.

It would be less work for authors to simply use a main element. Authors naturally use the semantics of a main content area (with classes, id etc.) thus if they were given a <code>main</code> element to use, they'd easily use that instead (paving a cowpath).

Browsers could (user-configurably) provide some sort of built-in skip to main content gesture (link, or other mechanism).

== Arguments for ==
In general there must be a high burden of justification for adding new elements, in order to keep the language easier and more usable overall. Every new element adds cost to learning/usability, and thus must more than make up for it in benefits.

=== paves a cowpath ===
A <code>main</code> element paves an already researched cowpath.

Or: it should have been included with header footer et al.

The introduction of <code><header></code>, <code><footer></code>, <code><aside></code>, <code><nav></code>, and <code><article></code> is based on careful consideration based on data gathered (in 2005).

Even according to Hixie’s research, the class “content” ranked higher than “nav” or “header”. It would be even more obvious if you took the sum of “content”, “main” and “body” (as class names or ids).

See https://developers.google.com/webmasters/state-of-the-web/2005/charts/top20-classes.svg .

That Hixie left <code><main></code> out in the first place is not justified by the research presented.

=== avoids last case of having to use an ARIA landmark ===
"Use of ARIA (a stop gap) should be a smell. Using it generally
implies a weakness in native semantic, or, an abuse of native semantics." -David Bolter

Additionally, role=main is the most commonly used ARIA landmark per:
* http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/
And it’s the only landmark that doesn’t have a one-to-one mapping to an HTML element name.

A main element would avoid the need to use role="main".

== Arguments against ==
=== Lack of concrete use case documentation ===
See previous [[Main_element#Use_cases|Use cases]] section.

=== main does not meet a high bar of inclusion ===
Per the research cited in [[Main_element#paves_a_cowpath|paves a cowpath]], a main element meets a higher bar than "article" for example (which has plenty of real world use in blog posts), and certainly more than "hgroup" (which is debatable whether it should be kept or not).

== Counter-proposals ==
=== Use existing markup instead ===
==== first article ====
Referred: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037826.html

Summarized:
* To Authors: just use <code><article></code>. The main contents of a page are worthy of independently syndicating - nearly all content on the web works this way today.
* To Accessibility Tools: If you don't find a role=main element, then just use the first <code><article></code> in the page as if it were a <code><main></code> element.

The use of <code><article></code> instead also makes sense as a generalization of <code><main></code> that arises as soon as one thinks of how to write processing rules for the case where a page has more than one <code><main></code> even if it isn’t supposed to have more than one <code><main></code>.

Questions:
* Q: Where's the end of <code><main></code> content?
** A: End of the last <code><article></code>.
* Q: How do you skip stuff between <code><main></code> elements?
** A: Skip stuff between <code><article></code> elements.
* Q: Is it appropriate to use <code><article></code> in the gmail message list?
** A: Yes, each message does have its own URL, and POP could arguably be a form of syndication.

===== problems with first article =====
Problems with the first article rule: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html][https://bugzilla.mozilla.org/show_bug.cgi?id=820508#c3]

1) The generalization no longer looks the way authors think. The
cowpath being paved is hard to recognize. That is, the idea that you
replace <code><div id=content></code> or <code><div id=main></code> with <code><main></code> is more intuitive than that you replace <code><div id=content></code> with <code><article></code> but
you also replace each <code><div class=comment></code> with <code><article></code> and since the comments come after the main article, the first <code><article></code> ends up having the semantics of main content.

2) When role="main" exists, it’s hard to convince people that implicit works as well as explicit. Even if browsers actually exposed the right accessibility API role for first <code><article></code>, authors would still probably feel it’s better to say role="main" just in case. I would love to see ARIA obsoleted in the sense that people who don’t retrofit accessibility to legacy code and who aren’t recreating GUI widgets is JS wouldn’t need to deal with ARIA (where including role=main just in case because one doesn’t trust rules like “first <code><article></code>” counts as “needing” to deal with ARIA).

3) Even though in principle, the element names are just runes whose
meaning is given by the spec—not by the English meaning of the element
name, people still try to guess usage from the element name. It’s
pretty easy to believe from element names alone than <code><main></code> is <code><div id=content></code> or <code><div id=main></code> made as a part of the language itself. It’s harder to grok the defined semantics of <code><article></code> from its element name.

4) It’s more obvious to write main { ... } in CSS than
article:first-of-type { ... }

5) "first article" fails to handle cases like:
<source lang=xml>
<section>
<h1>Heading</h1>
<aside> ... </aside>
<nav> ... </nav>
text...
<aside> ... </aside>
<aside> ... </aside>
text...
</section>
</source>

== Implementation impact ==
Notes on potential implementation impact of a main element on web browsers.

To be done right, <code><main></code> and <code><p></code> should interact the way e.g. <code><article></code> and <code><p></code> do.

Consider
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1939 and
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1940

vs.

* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1942 and
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1941

Implementer feedback:
* Mozilla:
** From a layout engine implementation point of view the burden is trivial.
** The parser change would be absolutely trivial. There is absolutely no basis for opposing <code><main></code> on the grounds of amount of parser change work needed.

== Implementation bugs ==
* Mozilla Firefox/Gecko: [https://bugzilla.mozilla.org/show_bug.cgi?id=820508 Bug 820508 Add support for <main> element]
* WebKit: [https://bugs.webkit.org/show_bug.cgi?id=103172 Bug 103172 - implement the HTML <main> element]

== Open issues ==
=== Different HTML parsing algorithms ===
It’s just unfortunate that if <code><main></code> was introduced, the HTML parsing algorithm wouldn’t be one exact thing but there’d be HTML parsing pre-<code><main></code> and HTML parsing post-<code><main></code> and during the transition, Web authors would have to explicitly write the </p> tag, which is supposed to be optional. However, we are headed to a world where there will be HTML parsing pre-<code><template></code> and HTML parsing post-<code><template></code> anyway.

== Asides ==
=== Mesolithic analogy ===
It's interesting that debates over introducing a term for "the middle part" of something long predate this discussion, see for example the controversy over the introduction of the term "mesolithic":

http://en.wikipedia.org/wiki/Mesolithic#History_of_the_concept

as the thing between, Paleolithic (header), and Neolithic (footer). Despite the controversy, mesolithic is now an established term.

User:Tantek

2012-12-11T21:34:33Z

Tantek: /* articles created */ main element

== hello!==
<div style="float:right">
__TOC__
</div>

<div class="vcard">Hi, I'm <span class="fn">Tantek Çelik</span> and my home page is <span class="url">http://tantek.com/</span>.
<div class="note">
I've been working on and advocating open web standards since 1998, in particular in the W3C CSS and HTML working groups, and have most recently written and published an HTML5 tutorial video/book:

* [http://tantek.com/html5now HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today]

I've also recently given several [[presentations]] on HTML5.

I am a contributor to HTML5, and encourage the web authoring/design/development community to add to the [[Main_Page|WHATWG Wiki]] and send feedback to the [http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org WHATWG list].
</div>
</div>

== public domain release ==
{{cc-public-domain-release}}

== disclosure ==
I'm currently (as of 2011-176) a Mozilla employee developing and coordinating work on web standards.

Much of this relates to HTML5.

See my [https://wiki.mozilla.org/Tantek-Mozilla-projects list of projects that I'm working on with Mozilla].

== articles created ==
=== elements ===
* [[cite element]]
* [[del element]]
* [[Input element]]
* [[main element]]
* [[summary element]]
=== attributes ===
* [[charset]]
* [[Content-Language]]
* [[Iframe Sandbox]]
* [[Img Alt]]
=== other ===
* [[Getting started with browser development]]
* [[Irc-people]]

=== templates created ===
* [[Template:Cc-public-domain-release]]
* [[Template:For]]
* [[Template:Irc_user]]
* [[Template:Stub]]

=== categories created ===
* [http://wiki.whatwg.org/wiki/Category:Public_domain_license Public domain license]

=== redirect articles created ===
* [[alt]]
* [[cite]]
* [[del]]
* [[Faruk]]
* [[Hixie]]
* [[input]]
* [[irc]]
* [[longdesc]]
* [[main]]
* [[Sandbox]]
* [[summary]]
* [[Tantek]]
* [[time]]

== articles edited ==
See my list of edits: [[Special:Contributions/Tantek]]

=== sections created ===
Created the following sections in existing articles:
* Main_Page
** [[Main_Page#Research_and_data|Research and data]]
* Table_Summary
** [[Table_Summary#Research|Research]]
* Time_Element
** [[Time_Element#year_only|year only]]
** [[Time_Element#year_month_only|year month only]]
** [[Time_Element#month_day_only|month day only]]

== see also ==

Main

2012-12-11T21:32:46Z

Tantek: r

#redirect:[[Main_element]]

Main element

2012-12-11T21:32:11Z

Tantek: draft based on mailing list discussion, and arguments I've heard both for and against

There is an HTML5 extension specification that proposes adding a <code>main</code> element to HTML5.

* https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

Summary: This page contains arguments for, rebuttals to arguments against, and research/data supporting the introduction of a <code>main</code> element to HTML/HTML5.

HTML5 has several new "block like" semantic elements (article, aside, section), including header and footer elements. There is no element to represent (and provide a hook for) for ''the'' "main content". The only landmark ARIA role that lacks an equivalent semantic HTML element is also called "main", and it is being used on real world websites.

This page contains:
* positive reasoning and supporting evidence for <code><main></code>
* arguments against <code><main></code>, with follow-ups
* counter-proposals to <code><main></code>, with explanation of inadequacies

== Use cases ==
Though there are some documentation of use-cases elsewhere, it's helpful to provide some of these in this context to help with consideration of the proposal.

=== Reduce need for explicit skip links ===
One of the motivators was to get rid of skip links (http://webaim.org/techniques/skipnav/).

A main element would reduce work for authors.

Adding skip links is extra work for the author, particularly for accessibility, and thus it can be missed.

It would be less work for authors to simply use a main element. Authors naturally use the semantics of a main content area (with classes, id etc.) thus if they were given a <code>main</code> element to use, they'd easily use that instead (paving a cowpath).

Browsers could (user-configurably) provide some sort of built-in skip to main content gesture (link, or other mechanism).

== Arguments for ==
In general there must be a high burden of justification for adding new elements, in order to keep the language easier and more usable overall. Every new element adds cost to learning/usability, and thus must more than make up for it in benefits.

=== paves a cowpath ===
A <code>main</code> element paves an already researched cowpath.

Or: it should have been included with header footer et al.

The introduction of <code><header></code>, <code><footer></code>, <code><aside></code>, <code><nav></code>, and <code><article></code> is based on careful consideration based on data gathered (in 2005).

Even according to Hixie’s research, the class “content” ranked higher than “nav” or “header”. It would be even more obvious if you took the sum of “content”, “main” and “body” (as class names or ids).

See https://developers.google.com/webmasters/state-of-the-web/2005/charts/top20-classes.svg .

That Hixie left <code><main></code> out in the first place is not justified by the research presented.

=== avoids last case of having to use an ARIA landmark ===
"Use of ARIA (a stop gap) should be a smell. Using it generally
implies a weakness in native semantic, or, an abuse of native semantics." -David Bolter

Additionally, role=main is the most commonly used ARIA landmark per:
* http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/
And it’s the only landmark that doesn’t have a one-to-one mapping to an HTML element name.

A main element would avoid the need to use role="main".

== Arguments against ==
=== Lack of concrete use case documentation ===
See previous [[Main_element#Use_cases|Use cases]] section.

=== main does not meet a high bar of inclusion ===
Per the research cited in [[Main_element#paves_a_cowpath|paves a cowpath]], a main element meets a higher bar than "article" for example (which has plenty of real world use in blog posts), and certainly more than "hgroup" (which is debatable whether it should be kept or not).

== Counter-proposals ==
=== Use existing markup instead ===
==== first article ====
Referred: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037826.html

Summarized:
* To Authors: just use <code><article></code>. The main contents of a page are worthy of independently syndicating - nearly all content on the web works this way today.
* To Accessibility Tools: If you don't find a role=main element, then just use the first <code><article></code> in the page as if it were a <code><main></code> element.

The use of <code><article></code> instead also makes sense as a generalization of <code><main></code> that arises as soon as one thinks of how to write processing rules for the case where a page has more than one <code><main></code> even if it isn’t supposed to have more than one <code><main></code>.

Questions:
* Q: Where's the end of <code><main></code> content?
** A: End of the last <code><article></code>.
* Q: How do you skip stuff between <code><main></code> elements?
** A: Skip stuff between <code><article></code> elements.
* Q: Is it appropriate to use <code><article></code> in the gmail message list?
** A: Yes, each message does have its own URL, and POP could arguably be a form of syndication.

===== problems with first article =====
[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html There are at least four problems with the first article rule]:

1) The generalization no longer looks the way authors think. The
cowpath being paved is hard to recognize. That is, the idea that you
replace <code><div id=content></code> or <code><div id=main></code> with <code><main></code> is more intuitive than that you replace <code><div id=content></code> with <code><article></code> but
you also replace each <code><div class=comment></code> with <code><article></code> and since the comments come after the main article, the first <code><article></code> ends up having the semantics of main content.

2) When role="main" exists, it’s hard to convince people that implicit works as well as explicit. Even if browsers actually exposed the right accessibility API role for first <code><article></code>, authors would still probably feel it’s better to say role="main" just in case. I would love to see ARIA obsoleted in the sense that people who don’t retrofit accessibility to legacy code and who aren’t recreating GUI widgets is JS wouldn’t need to deal with ARIA (where including role=main just in case because one doesn’t trust rules like “first <code><article></code>” counts as “needing” to deal with ARIA).

3) Even though in principle, the element names are just runes whose
meaning is given by the spec—not by the English meaning of the element
name, people still try to guess usage from the element name. It’s
pretty easy to believe from element names alone than <code><main></code> is <code><div id=content></code> or <code><div id=main></code> made as a part of the language itself. It’s harder to grok the defined semantics of <code><article></code> from its element name.

4) It’s more obvious to write main { ... } in CSS than
article:first-of-type { ... }

== Implementation impact ==
Notes on potential implementation impact of a main element on web browsers.

To be done right, <code><main></code> and <code><p></code> should interact the way e.g. <code><article></code> and <code><p></code> do.

Consider
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1939 and
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1940

vs.

* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1942 and
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1941

Implementer feedback:
* Mozilla:
** From a layout engine implementation point of view the burden is trivial.
** The parser change would be absolutely trivial. There is absolutely no basis for opposing <code><main></code> on the grounds of amount of parser change work needed.

== Open issues ==
=== Different HTML parsing algorithms ===
It’s just unfortunate that if <code><main></code> was introduced, the HTML parsing algorithm wouldn’t be one exact thing but there’d be HTML parsing pre-<code><main></code> and HTML parsing post-<code><main></code> and during the transition, Web authors would have to explicitly write the </p> tag, which is supposed to be optional. However, we are headed to a world where there will be HTML parsing pre-<code><template></code> and HTML parsing post-<code><template></code> anyway.

== Asides ==
=== Mesolithic analogy ===
It's interesting that debates over introducing a term for "the middle part" of something long predate this discussion, see for example the controversy over the introduction of the term "mesolithic":

http://en.wikipedia.org/wiki/Mesolithic#History_of_the_concept

as the thing between, Paleolithic (header), and Neolithic (footer).

Testsuite

2012-08-09T00:22:25Z

Tantek: How to license your test suite

== Requirements ==

* Each test needs a "reviewed" marker of some sort
* It must be easy to find tests where the spec has changed under them
* The barrier to contribution must be as low as possible
* Testcases should have somewhat stable URIs
* If test can be done using JavaScript preferably require it to be in JavaScript so engines can be more efficiently tested (i.e. automated).
* It must be easy to review tests
* Tests and test suites must be liberally licensed (e.g. PD/CC0, BSD, MIT)
* Standardize a test format?

== How to license your test suite ==

Put your test suite into the Public Domain using the [http://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Public Domain Dedication].

Example markup you can include in the test suite. Either one is sufficient. The visible one is preferred.

Visible (e.g. in a visible header/footer on the test suite home page):
<pre><nowiki>
This test suite is placed into the
<a rel="license"
href="http://creativecommons.org/publicdomain/zero/1.0/">
public domain using CC0
</a>.
</nowiki></pre>

Invisible (e.g. inside the <head> element on the test suite home page):
<pre><nowiki>
<link rel="license"
href="http://creativecommons.org/publicdomain/zero/1.0/"
title="This test suite is placed into the public domain using CC0." />
</nowiki></pre>

== Non-requirements ==

* There does not need to be a single consistent test harness for the whole of HTML5. (When sections can be tested in isolation, each section should use a test harness that is suited to that section's testing requirements. E.g. there is little value in fitting canvas tests and parser tests into the same framework, and it may add a lot of complexity.)

== Format proposal ==

See http://omocha.w3.org/wiki/newformat for a format proposal that should meet most of these requirements. That format is based on the Mozilla Mochitest format for running JavaScript based client-side tests which can be run automatically.

== Existing tests ==
* [[Test cases]]
* [http://www.whatwg.org/html5 The specification] has links to test in the status boxes.
* [http://samples.msdn.microsoft.com/ietestcenter/ IE's tests]
* [http://tc.labs.opera.com/html/ Opera's tests]
* [http://trac.webkit.org/browser/trunk/LayoutTests (Some of?) WebKit's tests]
* [http://mxr.mozilla.org/mozilla-central/find?string=test_.*%28html|svg%29%24&tree=mozilla-central&hint= Some of Mozilla's mochitests]
** [[Testsuite/Mozilla]]
* [http://mxr.mozilla.org/mozilla-central/find?string=reftest.list Some of Mozilla's reftests]
* [http://philip.html5.org/tests/canvas/suite/tests/ Philip's canvas tests]
* [http://hixie.ch/tests/adhoc/html/ Hixie's ad-hoc tests]
* [http://lachy.id.au/dev/markup/tests/html5/ Lachlan's tests]
* [http://hg.gsnedders.com/php-html-5-direct/file/tip/tests/numbersTest gsnedders' number parsing tests]
* [http://simon.html5.org/test/html/ zcorpan's tests]
* [http://mathias.html5.org/tests/ Mathias’s tests]
* [http://code.google.com/p/html5lib/source/browse/testdata html5lib tests]
* [http://hsivonen.iki.fi/test/moz/video-selection/ hsivonen's video tests]
* [http://www.w3.org/DOM/Test/ Document Object Model (DOM) Conformance Test Suites]
* [http://dev.w3.org/2006/webapi/WindowTestSuite/ Window test suite]

=== W3C ===
* [http://dev.w3.org/geo/api/test-suite/ Geolocation]
* [http://dvcs.w3.org/hg/webapps WebApps WG]
* [http://dvcs.w3.org/hg/html HTML WG]
* [http://hg.csswg.org/test CSS WG]

Test cases

2012-08-09T00:17:09Z

Tantek: Consider placing your test cases into the Public Domain using CC0

Consider placing all test cases you write into the Public Domain using the [http://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 1.0 Public Domain Dedication].

Example markup you can include in the test case or suite. Either one is sufficient.

Visible (e.g. in a visible header/footer on the test suite home page or test case):
<pre><nowiki>
This test suite/case is placed into the
<a rel="license"
href="http://creativecommons.org/publicdomain/zero/1.0/">
public domain using CC0
</a>.
</nowiki></pre>

Invisible (e.g. inside the <head> element on the test case page):
<pre><nowiki>
<link rel="license"
href="http://creativecommons.org/publicdomain/zero/1.0/"
title="This test suite/case is placed into the public domain using CC0." />
</nowiki></pre>

Existing test cases or test suites for HTML5.

* http://tc.labs.opera.com/html/ by [[User:Annevk|Anne van Kesteren]]
* http://tc.labs.opera.com/apis/getElementsByClassName/ by [[User:Annevk|Anne van Kesteren]]
* http://philip.html5.org/tests/canvas/suite/tests/ by Philip Taylor
* http://lachy.id.au/dev/markup/tests/html5/ by [[User:Lachlan_Hunt|Lachlan Hunt]]
* http://simon.html5.org/test/html/ by [[User:Zcorpan|Simon Pieters]]
* http://hasather.net/test/html/ by [[User:Hasather|David Håsäther]]
* http://code.google.com/p/html5lib/source/browse/testdata by html5lib contributors
* http://www.hixie.ch/tests/adhoc/html/ by [[User:Hixie|Ian Hickson]]
* http://webforms2.googlecode.com/svn/trunk/testsuite/index.html by [[User:westonruter|Weston Ruter]]
* http://mathias.html5.org/tests/ by [http://mathiasbynens.be/ Mathias Bynens]

See also: [[Testsuite]]

What you can do

2012-08-08T21:28:27Z

Tantek: /* How you can improve HTML */ l IRC

So you want to take part? You can!
* Review [http://whatwg.org/specs/ the specifications] and [http://whatwg.org/mailing-list#specs send comments]! (See below for details.)
* Write articles for our [http://blog.whatwg.org/ blog].
* Write [[Authoring|tutorials]] for new authors.
* Monitor and respond to questions on [http://www.whatwg.org/mailing-list#help the help list] and [http://forums.whatwg.org/ the forums].
* Maintain the document explaining the [[rationale]] of the decisions behind the spec. (See below for details.)
* Help to edit the [[FAQ]].
* Write [[test cases]].
* Write cool demos.
* [[:Category:Implementations|Implement HTML]]!
* Edit one of the many [[companion specifications]] that are lacking editors.

== Sending feedback ==
The most useful thing would be going through the spec and finding bits that don't make sense.

http://whatwg.org/html

You can use the widget at the bottom right (it says "Click the location of the error to select it, then type your message here:") to submit review comments on the spec. The best review comments are those along the lines of questions you couldn't find the answer to. For example, say you wanted to find out what elements you could put in a <p> element, and you couldn't work it out. Then you would file a bug "I couldn't find the answer to the question 'What elements are allowed inside <p> elements'.".

'''See also [[Reviewing]].'''

== A rationale document ==

It basically would consist of watching the e-mail lists, the Bugzilla
bugs, asking questions on [[IRC]], and then writing documentation to
explain the thinking behind different parts of the spec on the [[rationale]] page.

It could be as little work or as much work as you would want it to be. One
could easily imagine this becoming a group effort.

= How you can improve HTML =

''This is the text of an article Hixie wrote.''

Are you trying to do something on the Web that you find you can't do because HTML simply doesn't have a way to do it?

With your help, we can improve HTML, add a feature to address your problem, and in five to ten years you'll finally be able to do it!

Here's how:

First, write a description of the problem. What are you trying to do? This should be a high-level description. One way to see if you're describing it at a high
enough level is to consider whether your description makes as much sense for a Web developer as it does for, say, a mobile phone native app developer. So if your
description talks about HTML elements or JavaScript or HTTP headers, then it's probably too low level. If it talks about what a user sees, how a user interacts
with a computer or device, or how a user uses a computer or device to create some sort of content or effect some sort of change, then you're on the right path.
If you hear people referring to "use cases", it is to this problem description that they refer.

In particular, your description should not be a solution. Don't propose new elements or attributes, new APIs, new semantics, new features. The time for
discussions of solutions is later.

Next, do one or more of the following with this description:

0. Discuss the topic on our [[IRC]] channel (#whatwg on Freenode) to see if you've missed anything obvious

1. Post it to whatwg@whatwg.org

2. Post it on http://forums.whatwg.org/

3. Visit our IRC channel (#whatwg on Freenode) and ask for help posting it on our blog at http://blog.whatwg.org/

4. Post it as a bug report at http://whatwg.org/newbug (you'll need to create an account)

Participate in any resulting discussions. Post a link to your e-mail, forum post, blog post, or bug report to your own blog or to other social media sites to
encourage others to participate. For best results, I recommend that you avoid creating new places for the discussion to occur (e.g. new mailing lists, wiki
pages, or working groups). Keeping the discussions in existing places ensures that experience participants will see your discussions and will be able to
lend you their experience. The most important part of these discussions is clarifying how common the problem is, what related problems other people have
that could maybe be addressed at the same time, and what work-arounds exist to avoid the problem.

Ideally, some browser vendors will at this point start commenting on the problem, hopefully saying that they agree that it's a problem. Getting browser vendors
to believe there's a problem is the second best thing that you can do to ensure your problems gets solved. (The best thing that can happen is for browser vendors
to implement a solution. See notes below.) Once you have browser vendors buying-in to the problem's importance, you can start talking about possible solutions.
(You don't have to, though, and there's no guarantee that the solutions you propose will be adopted rather than some other ones.)

If you posted on the forums or on the blog, then once the discussion has settled down, ask for someone (e.g. zcorpan, for the forums, or whoever you spoke to on
IRC, for the blog) to forward your proposal to the main whatwg@whatwg.org mailing list. This will get the topic onto my (Hixie's) radar. (Bugs are all already
also on the radar, so you don't have to worry about those.)

Eventually, I will see the e-mail(s) or bug. This can take a few months, because there's a lot of feedback to go through. I then take all the information in the
thread, related forum posts and blog posts, and anything else I can find; I sometimes talk to browser vendors, bring the topic up on IRC for some sanity checking
with whoever is online, etc. And then I write a reply to all the e-mails, and possibly update the spec accordingly. Lather, rinse, repeat.

You may ask why browser vendors have a prominent role in this process. The answer is simple. The specification is not magical; it cannot force browser vendors to
do anything they don't want to do. If I write something in the spec and they don't implement it, there's nothing we can do: the feature doesn't really exist,
it's just fiction, and we've all wasted our time. To avoid wasting my time, I try to work with the browser vendors to make sure that what I specify is something
they're willing to implement. (It doesn't always work out that way, but then after a while I update the spec to match what they did do, or didn't do, e.g.
removing things that nobody has implemented.)

If you want to participate in the process in ways other than reporting problems you find with the Web, there are various things you can do: participate in
discussions on the mailing list, forums, blog, or bug system; chat with us on IRC (#whatwg on Freenode); write test cases; write tutorials; review the spec...
The best place to start is to join us on IRC and ask what you can do.

We also have a FAQ: http://wiki.whatwg.org/wiki/FAQ

Anolis

2012-05-30T20:23:59Z

Tantek: /* Setting up Anolis with cross-specification cross-references */

Anolis is a tool to generate specification-like documents out of simple HTML.

* http://pimpmyspec.net/
* http://hg.hoppipolla.co.uk/ -- jgraham's work
* http://bitbucket.org/ms2ger/anolis -- will hopefully be merged into jgraham's work

== Setting up Anolis with cross-specification cross-references ==

* Install http://bitbucket.org/ms2ger/anolis:
hg clone http://bitbucket.org/ms2ger/anolis
sudo python setup.py install
* install lxml and html5lib (actual install commands to be defined/tested/verified)
* In the directory where you have your specification clone https://bitbucket.org/ms2ger/specification-data as "data"
cd /mirror/hg/dvcs.w3.org/fullscreen/ # or wherever your spec is locally
hg clone https://bitbucket.org/ms2ger/specification-data data
* In the same directory create a Makefile equivalent to http://dev.w3.org/2006/webapi/progress/Makefile

[[Category:Spec coordination]]

Anolis

2012-05-30T20:11:29Z

Tantek: /* Setting up Anolis with cross-specification cross-references */

Anolis is a tool to generate specification-like documents out of simple HTML.

* http://pimpmyspec.net/
* http://hg.hoppipolla.co.uk/ -- jgraham's work
* http://bitbucket.org/ms2ger/anolis -- will hopefully be merged into jgraham's work

== Setting up Anolis with cross-specification cross-references ==

* Install http://bitbucket.org/ms2ger/anolis:
hg clone http://bitbucket.org/ms2ger/anolis
sudo python setup.py install
* In the directory where you have your specification clone https://bitbucket.org/ms2ger/specification-data as "data"
cd /mirror/hg/dvcs.w3.org/fullscreen/ # or wherever your spec is locally
hg clone https://bitbucket.org/ms2ger/specification-data data
* In the same directory create a Makefile equivalent to http://dev.w3.org/2006/webapi/progress/Makefile

[[Category:Spec coordination]]

Irc-people

2012-05-21T23:53:33Z

Tantek: add othermaciej

{{stub}}

A list of [[IRC]] regulars, sorted by nick, and their normal timezones (winter/summer).

* {{irc user|Adactio|adactio|+0000/+0100}}
* {{irc user|Annevk|annevk|.../...}}
* {{irc user|Dglazkov|dglazkov|.../...}}
* {{irc user|Hixie|Hixie|-0800/-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Jgraham|jgraham|.../...}}
* {{irc user|Ms2ger|Ms2ger|.../...}}
* {{irc user|Mjs|othermaciej|-0800/-0700}}
* {{irc user|ShaneHudson|ShaneHudson|+0000/+0100}}
* {{irc user|Xanthir|tabatkins|-0800/-0700}}
* {{irc user|Tantek|tantek|-0800/-0700}}
* {{irc user|Wilto|Wilto|.../...}}
* {{irc user|Zcorpan|zcorpan|.../...}}

== see also ==
* http://microformats.org/wiki/irc-people

Getting started with browser development

2012-05-16T17:42:55Z

Tantek: see also

{{stub}}

= Getting started with browser development =
Want to get started with browser development, e.g. help implement HTML?

== General Approaches ==
* finding and filing bugs to various browsers' bug databases is a great way to get involved

== Specific Browser Engines ==
Help with the development of specific browser engines. (alphabetical, please feel free to add/insert more).

=== Gecko ===
Gecko powers the Firefox browser.
* http://www.mozilla.org/contribute
* https://developer.mozilla.org/en/Introduction

=== Presto ===
Opera uses the Presto engine.
* http://opera.jobs/

=== Webkit ===
Webkit is used by Safari, Chrome, and recent BlackBerry browsers.
* http://www.webkit.org/building/checkout.html
* http://www.webkit.org/building/build.html

== See Also ==
* [[Specs]]

Getting started with browser development

2012-05-16T17:42:11Z

Tantek: '

User:Tantek

2012-05-16T17:41:24Z

Tantek: Getting started with browser development

== hello!==
<div style="float:right">
__TOC__
</div>

<div class="vcard">Hi, I'm <span class="fn">Tantek Çelik</span> and my home page is <span class="url">http://tantek.com/</span>.
<div class="note">
I've been working on and advocating open web standards since 1998, in particular in the W3C CSS and HTML working groups, and have most recently written and published an HTML5 tutorial video/book:

* [http://tantek.com/html5now HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today]

I've also recently given several [[presentations]] on HTML5.

I am a contributor to HTML5, and encourage the web authoring/design/development community to add to the [[Main_Page|WHATWG Wiki]] and send feedback to the [http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org WHATWG list].
</div>
</div>

== public domain release ==
{{cc-public-domain-release}}

== disclosure ==
I'm currently (as of 2011-176) a Mozilla employee developing and coordinating work on web standards.

Much of this relates to HTML5.

See my [https://wiki.mozilla.org/Tantek-Mozilla-projects list of projects that I'm working on with Mozilla].

== articles created ==
* [[charset]]
* [[cite element]]
* [[Content-Language]]
* [[del element]]
* [[Getting started with browser development]]
* [[Iframe Sandbox]]
* [[Img Alt]]
* [[Input element]]
* [[Irc-people]]
* [[summary element]]

=== templates created ===
* [[Template:Cc-public-domain-release]]
* [[Template:For]]
* [[Template:Irc_user]]
* [[Template:Stub]]

=== categories created ===
* [http://wiki.whatwg.org/wiki/Category:Public_domain_license Public domain license]

=== redirect articles created ===
* [[alt]]
* [[cite]]
* [[del]]
* [[Faruk]]
* [[Hixie]]
* [[input]]
* [[irc]]
* [[longdesc]]
* [[Sandbox]]
* [[summary]]
* [[Tantek]]
* [[time]]

== articles edited ==
See my list of edits: [[Special:Contributions/Tantek]]

=== sections created ===
Created the following sections in existing articles:
* Main_Page
** [[Main_Page#Research_and_data|Research and data]]
* Table_Summary
** [[Table_Summary#Research|Research]]
* Time_Element
** [[Time_Element#year_only|year only]]
** [[Time_Element#year_month_only|year month only]]
** [[Time_Element#month_day_only|month day only]]

== see also ==

Getting started with browser development

2012-05-16T17:39:22Z

Tantek: stub with links from IRC today

{{stub}}

= Getting started with browser development =
Want to get started with browser development, e.g. help implement HTML?

== General Approaches ==
* finding and filing bugs to various browser's bug databases is a great way to get involved

== Specific Browser Engines ==
Help with the development of specific browser engines. (alphabetical, please feel free to add/insert more).

=== Gecko ===
Gecko powers the Firefox browser.
* http://www.mozilla.org/contribute
* https://developer.mozilla.org/en/Introduction

=== Presto ===
Opera uses the Presto engine.
* http://opera.jobs/

=== Webkit ===
Webkit is used by Safari, Chrome, and recent BlackBerry browsers.
* http://www.webkit.org/building/checkout.html
* http://www.webkit.org/building/build.html

User:Tantek

2012-05-16T17:18:50Z

Tantek: update a few articles created

== hello!==
<div style="float:right">
__TOC__
</div>

<div class="vcard">Hi, I'm <span class="fn">Tantek Çelik</span> and my home page is <span class="url">http://tantek.com/</span>.
<div class="note">
I've been working on and advocating open web standards since 1998, in particular in the W3C CSS and HTML working groups, and have most recently written and published an HTML5 tutorial video/book:

* [http://tantek.com/html5now HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today]

I've also recently given several [[presentations]] on HTML5.

I am a contributor to HTML5, and encourage the web authoring/design/development community to add to the [[Main_Page|WHATWG Wiki]] and send feedback to the [http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org WHATWG list].
</div>
</div>

== public domain release ==
{{cc-public-domain-release}}

== disclosure ==
I'm currently (as of 2011-176) a Mozilla employee developing and coordinating work on web standards.

Much of this relates to HTML5.

See my [https://wiki.mozilla.org/Tantek-Mozilla-projects list of projects that I'm working on with Mozilla].

== articles created ==
* [[charset]]
* [[cite element]]
* [[Content-Language]]
* [[del element]]
* [[Iframe Sandbox]]
* [[Img Alt]]
* [[Input element]]
* [[Irc-people]]
* [[summary element]]

=== templates created ===
* [[Template:Cc-public-domain-release]]
* [[Template:For]]
* [[Template:Irc_user]]
* [[Template:Stub]]

=== categories created ===
* [http://wiki.whatwg.org/wiki/Category:Public_domain_license Public domain license]

=== redirect articles created ===
* [[alt]]
* [[cite]]
* [[del]]
* [[Faruk]]
* [[Hixie]]
* [[input]]
* [[irc]]
* [[longdesc]]
* [[Sandbox]]
* [[summary]]
* [[Tantek]]
* [[time]]

== articles edited ==
See my list of edits: [[Special:Contributions/Tantek]]

=== sections created ===
Created the following sections in existing articles:
* Main_Page
** [[Main_Page#Research_and_data|Research and data]]
* Table_Summary
** [[Table_Summary#Research|Research]]
* Time_Element
** [[Time_Element#year_only|year only]]
** [[Time_Element#year_month_only|year month only]]
** [[Time_Element#month_day_only|month day only]]

== see also ==

Irc-people

2012-05-16T17:09:47Z

Tantek: add a few more

{{stub}}

A list of [[IRC]] regulars, sorted by nick, and their normal timezones (winter/summer).

* {{irc user|Adactio|adactio|+0000/+0100}}
* {{irc user|Annevk|annevk|.../...}}
* {{irc user|Dglazkov|dglazkov|.../...}}
* {{irc user|Hixie|Hixie|-0800/-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Jgraham|jgraham|.../...}}
* {{irc user|Ms2ger|Ms2ger|.../...}}
* {{irc user|ShaneHudson|ShaneHudson|+0000/+0100}}
* {{irc user|Xanthir|tabatkins|-0800/-0700}}
* {{irc user|Tantek|tantek|-0800/-0700}}
* {{irc user|Wilto|Wilto|.../...}}
* {{irc user|Zcorpan|zcorpan|.../...}}

== see also ==
* http://microformats.org/wiki/irc-people

Irc-people

2012-05-15T21:37:04Z

Tantek: adactio

{{stub}}

A list of [[IRC]] regulars, sorted by nick, and their normal timezones (winter/summer).

* {{irc user|Adactio|adactio|+0000/+0100}}
* {{irc user|Annevk|annevk|.../...}}
* {{irc user|Hixie|Hixie|-0800/-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Ms2ger|Ms2ger|.../...}}
* {{irc user|Tantek|tantek|-0800/-0700}}
* {{irc user|Wilto|Wilto|.../...}}

== see also ==
* http://microformats.org/wiki/irc-people

Irc

2012-05-15T21:35:27Z

Tantek: r

#redirect:[[IRC]]

Irc-people

2012-05-15T21:33:22Z

Tantek: stubbed

{{stub}}

A list of [[irc|IRC]] regulars, sorted by nick, and their normal timezones (winter/summer).

* {{irc user|Annevk|annevk|-0800/-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Hixie|Hixie|-0800/-0700}}
* {{irc user|Ms2ger|Ms2ger|.../...}}
* {{irc user|Tantek|tantek|-0800/-0700}}
* {{irc user|Wilto|wilto|.../...}}

== see also ==
* http://microformats.org/wiki/irc-people

Template:Irc user

2012-05-15T21:26:57Z

Tantek: copied from http://microformats.org/wiki/Template:irc_user

IRC

2012-05-15T21:23:53Z

Tantek: irc people

The Freenode IRC network has a channel called [irc://irc.freenode.org/whatwg #whatwg] where some of the more active WHATWG community members hang out. Feel free to join us!

If you want to run a bot, let us know. If they are useful, e.g. providing logging facilities or watching the Subversion repository, then they are more than welcome.

== Logs ==
http://krijnhoetmer.nl/irc-logs/ has the logs for #whatwg.

== People ==
* [[irc-people]]

Time element

2012-05-03T21:58:10Z

Tantek: note change proposal for 'era'

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.
* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

User:Tantek

2012-04-19T06:28:57Z

Tantek: update disclosure

== hello!==
<div style="float:right">
__TOC__
</div>

<div class="vcard">Hi, I'm <span class="fn">Tantek Çelik</span> and my home page is <span class="url">http://tantek.com/</span>.
<div class="note">
I've been working on and advocating open web standards since 1998, in particular in the W3C CSS and HTML working groups, and have most recently written and published an HTML5 tutorial video/book:

* [http://tantek.com/html5now HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today]

I've also recently given several [[presentations]] on HTML5.

I am a contributor to HTML5, and encourage the web authoring/design/development community to add to the [[Main_Page|WHATWG Wiki]] and send feedback to the [http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org WHATWG list].
</div>
</div>

== public domain release ==
{{cc-public-domain-release}}

== disclosure ==
I'm currently (as of 2011-176) a Mozilla employee developing and coordinating work on web standards.

Much of this relates to HTML5.

See my [https://wiki.mozilla.org/Tantek-Mozilla-projects list of projects that I'm working on with Mozilla].

== articles created ==
* [[charset]]
* [[cite element]]
* [[Content-Language]]
* [[del element]]
* [[Iframe Sandbox]]
* [[Img Alt]]
* [[summary element]]

=== templates created ===
* [[Template:Cc-public-domain-release]]
* [[Template:Stub]]

=== categories created ===
* [http://wiki.whatwg.org/wiki/Category:Public_domain_license Public domain license]

=== redirect articles created ===
* [[cite]]
* [[Faruk]]
* [[Hixie]]
* [[longdesc]]
* [[summary]]
* [[Tantek]]
* [[time]]

== articles edited ==
See my list of edits: [[Special:Contributions/Tantek]]

=== sections created ===
Created the following sections in existing articles:
* Main_Page
** [[Main_Page#Research_and_data|Research and data]]
* Table_Summary
** [[Table_Summary#Research|Research]]
* Time_Element
** [[Time_Element#year_only|year only]]
** [[Time_Element#year_month_only|year month only]]
** [[Time_Element#month_day_only|month day only]]

== see also ==

Time element

2012-01-14T23:50:25Z

Tantek: /* tz attribute */ fix discussion heading

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== tz attribute discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2012-01-14T23:18:48Z

Tantek: document tz attribute proposal from Marat Tanalin

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===
<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

== tz attribute ==
As quoted from the part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin].

;Status
:new
;Summary
:Add dedicated @tz attribute to specify exact timezone (if any)

"@tz attribute can contain timezone offset in hours (with leading dash used in value for negative offsets).

Note that @tz attribute has nothing to do with timezone as TIME element value itself. @tz attribute is intended to be used in conjunction with datetime value provided separately: either by element's contents or by @datetime attribute value.

Advantage of using dedicated attribute for timezone is that it can be applied to date represented by TIME element's <em>contents</em>, thus preventing authors from duplicating date partially or entirely in both contents <em>and</em> @datetime attribute.

The @tz attribute is optional."

=== tz attribute examples ===
<code><time <strong>tz="-8"</strong>>2011-11-12 19:20</time></code>

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin (proposer) per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal]
* -1 Tantek - I think separating machine datetime data into multiple attributes is not as reliable as always just using one (the current "datetime") attribute, especially from an authoring data quality expectations perspective.
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T23:47:36Z

Tantek: /* permit space instead of T in datetimes */ status - adopted in WHATWG HTML.

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
;Status
:[http://html5.org/r/6845 2011-12-06] '''Adopted in WHATWG HTML.'''[http://krijnhoetmer.nl/irc-logs/whatwg/20111207#l-5]
;Summary
:The date-and-time microsyntaxes should permit a single space as a separator as an alternative to "T".

=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T23:42:02Z

Tantek: /* existing implementation support of date-space-time */ postgresql

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''postgresql''' "also accepts that format, and its commandline omits T by default as well (2011-12-06 15:27:00.706385-07)" -zewt [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1138]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T23:40:26Z

Tantek: /* date-space-time discussion */ +1 zewt

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* +1 zewt "it's a natural, human format, where *T* really isn't" [http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1131]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T23:24:50Z

Tantek: /* existing implementation support of date-space-time */ note IE8 doesn't support datetime with 'T' either

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
**** also returns NaN for "2011-11-11T11:11:11"[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1127] - thus unclear that lack of space support is any kind of meaningful result.
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T22:20:31Z

Tantek: /* existing implementation support of date-space-time */ ]

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199]
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T22:20:09Z

Tantek: /* existing implementation support of date-space-time */ IE8 returns NaN

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 returns NaN[http://krijnhoetmer.nl/irc-logs/whatwg/20111206#l-1126]. However it does support the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]

Time element

2011-12-06T22:11:27Z

Tantek: /* Syntax improvements */ permit space instead of T in datetimes, scope reducing DRY violations intro explanation

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element HTML5 <code>time</code> element] (see also [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element W3C TR time snapshot]).

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, use-cases, evidence and - hopefully - support in the respective discussion sections.

Thanks for your consideration,

[[User:Tantek|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 [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.

=Date granularity=
== year only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year.
;ISO8601 syntax
:YYYY
=== year only use cases ===
use case research:
* http://microformats.org/wiki/birthday-examples#year_only
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year and circa dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
*Citations from a bibliography which list two or more works by the same author disambiguate them by year
*Commerce
** "a piece of jewellery hallmarked 1933"
** "a 1973 Chevy"
*Sport
**2008 Olympics
**1966 World Cup
*Awards
**"1973 Oscar for best film"
**"1988 Nobel Peace Prize"
*Restyling dates for localisation and to follow user conventions
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)
* Relative dates in texts: news websites and blogs often use phrases such as
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]

=== year only discussion ===
<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.
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* +1 [[User:Drublic|drublic]] - As input-fields support `year` the datetime-attribute as it is (was until <time datetime="2011-10-20">yesterday</time>) should also allow users to define year-only dates. Furthermore it will help making newspapers, wikis and quotations more accessible and semantically powerful.
* ...
</div>

=== year only related posts ===
Related posts (listed with quotes directly related to year only) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote>

=== year only next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-only dates in the time element.

== year month only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:The time element should accept just a year and a month.
;ISO8601 syntax
:YYYY-MM

=== year month use cases ===
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)
** http://www.flickr.com/photos/tantek/archives/
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)
* output equivalent of <code><input type="month"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].
* use cases in VCARDDAV & EDTF - see external links
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]
* Photo date taken
** [http://laughingmeme.org/2011/06/02/flourishes-craftsmanship-dates-history-and-flickr/ Flickr supports year-month dates] - "Flickr taken dates come in 4 levels of granularity, exact, year-month, year, and circa."
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)
* Restyling dates for localisation and to follow user conventions
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]

=== year month discussion ===
<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)
* +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:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.
* ...
</div>

=== year month related posts ===
Related posts (listed with quotes directly related to year-month) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote>
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote>
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote>
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the <nowiki>[sic]</nowiki> 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″.</blockquote>

=== year month next steps ===
Per this edit/comment from Ian: http://lists.w3.org/Archives/Public/public-html-diffs/2010Aug/0234.html

We need to help create a CSS feature for styling dates to local conventions (e.g. 2000-12-31 vs 31-12-2000 vs 12-31-2000 vs Japanese conventions for year and year-month). Once such a CSS feature exists, it will apparently provide additional weight for including year-month dates in the time element.

== year week only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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 <code><input type="week"></code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

;reasoning
:to provide the output equivalent of <code><input type="week"></code>

See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]] per good design of impedance matching date time inputs.
* ...
</div>

== month day only ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
: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
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html 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.

<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)
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.
* ...
</div>

= 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 <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

<pre><nowiki>
<input type="date"> - <time>YYYY-MM-DD</time>
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)
<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)
<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"> - <time>YYYY</time> (as of 2011-11-18)
<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)
</nowiki></pre>

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

* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].

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

* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].

<div class="discussion">
Opinions / discussion:
* +1 [[Tantek]]
* +1 [[User:Pigsonthewing|Andy Mabbett]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]]
* ...
</div>

= 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 allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

;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."[http://www.zeldman.com/superfriends/guide/#time]
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (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. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]
:4 ...

<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
* +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].)
* 0 (comments) [[User:Tantek|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)
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre>
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 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 [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"
* +1 [[User:asbjornu|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 [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)
****Done. [[User:Pigsonthewing|Pigsonthewing]] 11:24, 23 August 2010 (UTC)
* ...
</div>

== Calendar scale ==
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 one of a set of pre-defined CALSCALE types.

=== Calendar scale example ===
Example:

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

=== 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 [http://www.zeldman.com/superfriends/guide/#time 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 <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - 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 [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]:
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.
* Documenting pre-Gregorian time travel in science fiction
**[http://www.guardian.co.uk/news/datablog/2010/aug/20/doctor-who-time-travel-information-is-beautiful Dr Who time travel]
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar

=== Calendar scale discussion ===
<div class="discussion">
Opinions / discussion:
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)
* 0 [[User:Tantek|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 <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)
* +1 [[User:crashposition|John Dalziel]] Non-Gregorian reckoning is common in many fields (history, archeology, geology and astronomy to name just a few). However, given that all standard temporal datatypes are derived from ISO8601 then I think we're currently stuck with Gregorian for machine-readable dates. This puts the onus on the author to make (an often error-prone) conversion to Gregorian.
* …
</div>

=== Calendar scale related posts ===
Related posts (listed with quotes directly related to Calendar scale) :
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">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.</blockquote>
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> 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
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>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.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.

= Syntax improvements =

== permit space instead of T in datetimes ==
=== summary of permit date-space-time ===
Current date-and-time microsyntaxes require a "T" between the date and time per ISO8601:
2011-12-06T13:28:00

This proposal modifies that requirement to permit a single space (U+0020) instead of the "T", for both better human readability and the fact that that slight modification of ISO8601 date-and-time syntax is already widely supported by various tools.
2011-12-06 13:28:00

This proposal should be applied to the 'datetime' attribute of both the <code><time></code> element and the <code><ins></code> & <code><del></code> elements.

Inspired by the first part of [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime this proposal by Marat Tanalin], with additional references/issues documented from [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-959 #whatwg on 2011-12-01].

=== existing implementation support of date-space-time ===
Note that this specific proposal of allowing a single space instead of "T" is supported by several existing implementations:
* '''Python.''' The date time python module outputs " " instead of "T" for <code>[http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__ str(aDatetime)]</code>.
* '''MySQL.''' MySQL takes and sends all its [http://dev.mysql.com/doc/refman/5.1/en/datetime.html dates in date-space-time format].
* '''Perl.''' "Perl's Date::Parse also takes dates in that format, although it's not int he documentation. But we've been relying on it doing so, for years, in Bugzilla." -mkanat [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1129]
* '''Javascript Date.parse method.'''
** '''Chrome''' can parse it "2011-11-11 11:11:11".[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1138],[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1140]
** '''Opera''' [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1141]
** Notable exceptions that DO NOT parse it:
*** Firefox8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1136]
*** IE8 [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1142 appears to support it], but only actually supports the format it outputs from toString ("Thu Dec 1 16:10:18 EST 2011")[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1209]
*** IE9 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1199
*** IE10 returns NaN [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1196]
*** Safari returns NaN for: <br/><code>data:text/html,<!doctype html><script>alert(Date.parse("2011-11-11 11:11:11"))</script></code>

=== date-space-time issues questions ===
==== gratuitous departure from ISO8601 ====
"...seems like a bit of a gratuitous departure from ISO8601"

It's not gratuitous because there are very specific reasons for it:
* it does help readability, incrementally
* we're only adopting something that's been in use for a while, that is, it's been a mod on ISO8601 in general by others.

=== date-space-time discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Marat Tanalin per [http://www.w3.org/wiki/User:Mtanalin/time_element#h-simplify-datetime].
* +1 [[Tantek]] - I think this will improve readability, writability, usability, and thus overall data quality for information expressed in the date-and-time microsyntax.
* +1 kennyluck per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1106]. "I think this <nowiki>[ISO8601-with-space]</nowiki> is the most i18n-wise human-readable format."[http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1111]
* +1 mkanat per [http://krijnhoetmer.nl/irc-logs/whatwg/20111201#l-1109]
* ...
</div>

== <span id="Syntax_improvements_for_reducing_DRY_violations">reducing DRY violations overview</span> ==

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 - '''D'''on't '''R'''epeat '''Y'''ourself - 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 duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).

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 [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].

In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time datetime="17:43:29">5:43pm</time>
</time>
</nowiki></pre>

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

The <em>separate</em> date and time <code>datetime</code> attribute 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:

<pre><nowiki>
<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>
</nowiki></pre>

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:

<pre><nowiki>
<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>
</nowiki></pre>

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 and related processing.

=== simple nested time example improvement ===
We'd like to have our <code><time></code> and date time separation as well, so this should work:

<pre><nowiki>
<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>
</nowiki></pre>

=== summary of updated datetime algorithm ===
In short: the algorithm for determining the "datetime" of a time element should:
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)
# 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)
# 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> 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:

<pre><nowiki>
<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>
</nowiki></pre>

Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> 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 ===
<div class="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 [[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.
** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible *world-wide* per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek|Tantek]]
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
<pre><nowiki>
<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 datetime="2005-10-05/2005-10-07">
<time class="dtstart">October 5</time>-
<time class="dtend">7</time>
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div></nowiki></pre>
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)
** In addition, the ISO8601 intervals syntax are sufficiently unfriendly/unintuitive/unreadable that they've been rejected for hCalendar in the past. This particular proposal should be evaluated on its merits independent of intervals. Intervals would need to be discussed as a separate feature. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* -1 [[User:cobaco]] We have 2 pieces of information 1) the actual date (in ISO format) and 2) how we want that time displayed. Pretty much every programming language under the sun already has code to transform a particular datetime into a particular format. So how about we just add an attribute, say datetimeformat. You'd then have something like:
<time datetime="2011-10-02T11:23:04" datetimeformat="%a, %e %b %Y %H:%M:%S %z" /> to get "Sun, 2 Oct 2011 11:23:04 +0200" displayed by the browser (I used a ruby strftime format specification to specify a rfc2822 datetime output, see http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_time.html#Time.strftime for how that works)
** Because syntaxes like "%a, %e %b %Y %H:%M:%S %z" are even more cryptic/esoteric/unreadable, and not something we'd want to burden web authors/designers with. In addition, the author/designer preferred human-specific format has to be provided literally as text in order for browsers that don't support the time element to render it. [[User:Tantek|Tantek]] 01:31, 24 November 2011 (UTC)
* ...
</div>

== 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 [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)

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

We want to be able to do this:

<pre style="background:#efe"><nowiki>
<time class="published">
<time datetime="2009-12-13">Sunday, December 13th, 2009</time>
<time>5:43pm</time>
</time>
</nowiki></pre>

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:

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

Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.

=== am pm example with nested time elements ===
Example (uses aforementioned composite nested time element proposal as well)

<pre><nowiki>
<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>
</nowiki></pre>

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

=== am pm discussion ===
<div class="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) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)
* ...
</div>

=== am pm FAQ ===
==== noon and midnight ====
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight 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.

= Other types of time =
== duration ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing durations as well for the use cases as needed by the [http://microformats.org/wiki/hmedia hMedia] and [http://microformats.org/wiki/haudio hAudio] microformats as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** PnD,nH,nM,nS
*** where P, D, H, M, S are case-insensitive literals
*** P is optional
*** n is a fixed point number expressible with a decimal point
*** and the intervening commas ',' are optional and may be used when more than one time duration unit is given.
** PnDTnHnMnS (per informative reference: [http://en.wikipedia.org/wiki/ISO_8601#Durations ISO8601 duration])
*** where P, D, T, H, M, S are case-insensitive literals
*** n is a non-negative integer (with optional leading zeroes)

Note: per discussion 2011-321 in #whatwg IRC, and explicitly noting that iCalendar RFC 5545 omits year and month durations from its subset of ISO8601 duration syntax, this proposal also omits year and month durations. Without documented examples of in-the-wild publishing weeks durations (which are present in iCalendar), they are also omitted. Documentation of real world examples may help reconsideration of weeks durations.

=== duration examples ===
<pre>Typical bims are <time datetime="P61D">61 days</time> long.</pre> (source: [http://newcal.org/#bimdefinition NewCalendar bim defintion])

<pre>"The Game Has Changed" <time datetime="P3M,25S">3:25</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/Tron:_Legacy_%28soundtrack%29#Track_listing Wikipedia: TRON:Legacy soundtrack track listing])

<pre>Length <time datetime="P42M,59S">42:59</time></pre> (source: [https://secure.wikimedia.org/wikipedia/en/wiki/The_Dark_Side_of_the_Moon Wikipedia: The Dark Side of the Moon]); existing markup is:
<pre><tr class="">
<th scope="row" style="text-align:left;">Length</th>
<td class="" style=""><span class="duration"><span class="min">42</span>:<span class="s">59</span></span></td>
</tr></pre>
within an hAudio microformat.

<pre>The movie is <time datetime="96m">96 min.</time></pre> (source: [http://www.imdb.com/title/tt0084827/ IMDB:TRON])

=== duration faq ===
* Q: Why not re-use the literal [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations ISO 8601 duration] syntax?
** A: The ISO 8601 duration PnYnMnDTnHnMnS is quite human unfriendly and thus increases the chances of DRY violation based duplicate data drift. We've had experience with the usability/readability problems of the ISO8601 datetime syntax just with the T and without dashes "-" or colons ":" between the date and time components respectively, and it is not unreasonable ton conclude that similar usability/readability problems exist with the unpunctuated duration syntax PnYnMnDTnHnMnS. Thus we make a few explicit changes from the ISO 8601 duration syntax to eliminate those problems:
*** "," comma separated duration components (much more readable for humans)
*** dropping of the "T" between date and time components
*** reserve "Mo" standard abbreviation for Months for future disambiguation.

=== duration discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* +1 Singpolyma, though I think I'd prefer to also support the actual syntax if someone uses it
** +1 on your suggestion of also supporting the ISO-8601 duration format literally - since we can do so without conflict. [[User:Tantek|Tantek]] 02:55, 15 July 2011 (UTC)
** Note: I've updated this proposal since your comment (dropping months, years, and updating syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)
** updated accordingly. [[User:Tantek|Tantek]] 20:17, 4 November 2011 (UTC)
* +1 Andy Mabbett ([[User:Pigsonthewing|Pigsonthewing]]) (as Wikipedia editor who deployed hAudio there; see [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Infobox_album Album template] which uses [https://secure.wikimedia.org/wikipedia/en/wiki/Template:Duration Duration template])
** Note: I've updated this proposal since your comment (dropping months and years - neither of which is needed by the examples you provied, and updating the syntax), please feel free to follow-up with an updated opinion. [[User:Tantek|Tantek]] 06:07, 18 November 2011 (UTC)

* ...

</div>

Additional changes to consider:
<div class="discussion">
* '''separate 'duration' attribute.''' It's been pointed out on IRC that using an attribute called 'datetime' for publishing/representing durations is a bit of an abuse. It may introduce some amount of cognitive dissonance for authors as well. Thus one possible fix is to:
** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
</div>

== timezone ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6826&to=6827 2011-11-18] '''Adopted in WHATWG HTML.'''
;Summary
:It would be great if the time element could support expressing timezone as well for the use cases as needed by the [http://microformats.org/wiki/hcalendar hCalendar] and other microformats that indicate time (hAtom etc.) as well as other use-cases (Wikipedia, IMDB).

Simple proposal:

* Allow for also parsing the following:
** -HHMM
** Z
** +HHMM
** Where -, +, and Z are literals.
** Where HH is a two digit number (zero padded for values less than 10) that represents hours
** Where MM is a two digit number (zero padded for values less than 10) that represents minutes
* And interpret the result as a timezone offset.

=== timezone examples ===

<pre><code><time datetime=-0700>Pacific Daylight</time></pre> (source: [https://twitter.com/t/status/132158056736899073] in reply to [https://twitter.com/brucel/status/132152499032440833])

... more examples welcome (e.g. see [http://microformats.org/wiki/hcalendar-examples-in-wild] for extracting more)

=== timezone discussion ===
<div class="discussion">
Opinions / discussion:
* +1 Tantek (proposer).
* ...

</div>

= Minor editorial fixes =

== Update hCalendar example ==
;Status
:[http://html5.org/tools/web-apps-tracker?from=6830&to=6831 2011-11-18] '''Fixed in WHATWG HTML'''. See also [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14696 bug 14696].
;Summary
:please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.

=== Current example ===

The HTML5 spec currently has this hCalendar example:

<pre><nowiki>
<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.)
</nowiki></pre>

This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.

=== Updated example ===

Here is a suggested update:

<pre style="background:#efe"><nowiki>
<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>
</nowiki></pre>

The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue 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.

<div class="discussion">
Opinions / discussion:
* 0 (comment) [[User:Pigsonthewing|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 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.
* ...
</div>

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

* [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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith
* [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/spec.html EDTF proposals] (use-cases)
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]
** mailing list was datetime-comments@w3.org. - anyone have archives URL?
* [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)]
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]
* Dublin Core terms, e.g.
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.

[[Category:Proposals]]