WHATWG Wiki - User contributions [en]

FAQ

2011-02-24T17:12:50Z

Oli: /* What are the various versions of the spec? */ added a link to Web Applications 1.0 in table so column made sense

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is the HTML standard. The WHATWG also works on Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events, and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== “Living specification” sounds like a draft that may and will change at any moment and is probably not even complete at any moment of time... ===

That's exactly what it is. However, the specification does not change arbitrarily: we are extremely careful! As parts of the specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compat unless for security reasons). The specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

You can see which parts of the spec are stable and which are not from the status annotations in the left margin.

=== Don’t browsers need a target to work their implementations towards, even if it’s a snapshot that is essentially arbitrary? ===

In practice, implementations all followed the latest specs draft anyway, not the latest snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.

=== When will it be safe to attempt to implement the spec based solely on the formal specification statements in the spec? ===

It's never truly safe; for example, if you tried to implement HTML4 according to the HTML4 specification you wouldn't have an implementation compatible with HTML4-era documents. However, if you're able to deal with minor changes, like security updates, errata-level changes, etc, then you can see which parts of the spec are stable and which are not from the status annotations in the left margin.

In general, though, we would strongly recommend taking part in the development effort. There's a [http://www.whatwg.org/mailing-list#imps mailing list for implementors] which can help.

=== How do we know what to use, without having some sort of snapshot that browsers can aim at and developers can evaluate? ===

The same way you do ''with'' snapshots. Browser vendors don't look at the last snapshot, they look at the ever-progressing latest text anyway.

No browser ever implemented all of HTML4, for example, even in the years after it was a formal Recommendation. Nor did they wait til they had done all of HTML3.2 before working on implementing HTML4. They all picked and chose the bits they thought were useful. With the Living Standard approach, we can also update the specification at the same time to remove the bits they all agree are useless, and to add new features that they think we should add (before they go off and invent their own solutions!).

=== Isn’t the whole point of a specification to establish fixed point of reference so that all parties implementing the standard can ensure they have a common baseline of compatibility? ===

No, the point of a specification is to provide an accurate description of what all the parties should implement. When an error is found in this description, it's better to fix it than to leave it.

HTML4 provides an example of this. HTML4 says the default value for the "media" attribute is "screen", even though it was long ago realised that this made no sense and the default should be "all". The browsers all implement it as "all". A snapshot with a known bug is not as useful as a living standard.

=== The large Web industry with many browsers and even more producers of web pages needs to evolve in reasonably consistent steps for ubiquity and interoperability, so we need snapshots ===

It's true that "the large Web industry with many
browsers and even more producers of web pages needs to evolve in
reasonably consistent steps for ubiquity and interoperability". However, unchanging snapshots of specifications
do nothing to help with this. The implementations usually follow the
drafts, not the snapshots, and in the exceptions where they don't, they
end up ''failing to interoperate''.

Consider what would happen if a Web browser vendor decided to implement
HTML4 instead of the latest state of the HTML Living Standard. That vendor would have <link>
elements with the wrong media="" attribute default, which would break
printing of most of the Web. That vendor would misparse <p><table>, which
would result in blank lines in numerous unexpected places. That vendor
would find that pages that styled empty paragraphs would fail to render as
expected. That vendor would find that millions of pages would be
unparseable due to not assuming a default encoding. That vendor would find
that 0.2% of pages were missing images due to HTML4 not requiring the
<image>/<img> aliasing. That vendor would, in short, find that the
spec was not an accurate description of the Web, and would either fail in
the market place (due to lack of interoperability), or would go seeking
the latest spec, the living standard, which would dramatically improve their interoperability
with legacy content and existing browsers.

Snapshots harm interoperability, they don't help it.

=== How about support in browsers for previous versions of this “living” HTML standard? ===

Browsers only need to implement the latest spec, and they will be compatible with the bulk of legacy content. That is an underlying principle of the entire WHATWG effort.

To clarify, browsers today don't implement separate modes for HTML2, HTML3.2, and HTML4. They just implement one version of HTML, and it works with everything (we call this "backwards compatibility"). This is the same model followed by the HTML specification; that's why it defines the browser requirements for lots of old features that aren't allowed anymore. For example, the "font" element is no longer conforming (authors aren't supposed to use it in their pages), but the spec still defines how it works, so that old pages keep working.

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this.

=== This means you will only able to add to a spec, not redefine it. ===

Yes. That's been a guiding principle for the WHATWG since its founding. It's even in our [http://www.whatwg.org/charter charter].

=== How can web developers know which features are safe to use? ===

See "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== Browsers can currently say they implement HTML 4.01 and most know what to expect. ===

Actually, that really isn't what happens in practice. Browsers do not implement specifications atomically, one spec at a time. They pick and chose features from the specs as they see fit. For example, back in the day, browsers implemented the absolute positioning parts of CSS2, but not 'display:run-in', but they still claimed to implement CSS2, and they already had parts of CSS3 implemented too, but not any part of a complete CSS3 module. Browsers claim to implement HTML4, but didn't implement all of it. Browsers moved on to HTML4 features before they had done all of HTML 3.2. And so on.

Plus, there's the problem of bugs. Different browsers have different bugs, and nothing in the spec's version can tell you what bugs the browser has.

Thus, in practice, you really can't tell what is implemented based on what version of what spec the vendor's marketing department claims to support. So not having a version number doesn't hurt. If anything, it helps, by removing a potentially bogus point of comparison — it means you have to compare browsers on what they really do (with a test suite), not on what version they claim to support.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week!

=== How will anything be deprecated and removed if there are no version numbers? ===

Not having version numbers doesn't stop us from removing features. We do that regularly, as described above in "[[FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F|Is there a process for removing bad ideas from a specification?]]". See also the "obsolete features" section in the HTML standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html

=== Will HTML become a bloated unimplementable mess as old features pile up if there are no version numbers? ===

No. We endeavour to not make HTML unimplementable — if it can't be implemented, there's not much point having a spec! Indeed, making HTML implementable is the main goal of the specification. Certainly HTML will continue to become complicated over time, but that is unrelated to whether we have version numbers or not.

=== Will HTML become an unusable mess as features are removed and old valid documents suddenly become invalid, if there are no version numbers? ===

No.

Features being invalid doesn't make them stop working — browsers are required to support old features. Even things like "inindex", framesets, "font", and so forth are still defined in the HTML specification, even though they're not to be used by authors. Old documents become invalid all the time, for example HTML 3.2 documents that use the "font" element were not valid HTML4 Strict documents, since it made "font" invalid (for good reasons, e.g. it tends to lead to authoring practices that harm accessibility). So even if we continue to make certain features invalid, it does not make HTML an "unusable mess".

=== If you do not publish snapshots every now and again, you are Orwellian in your recognition of the role the mistakes of the past play into the present and the future. ===

''No really, someone [http://blog.whatwg.org/html-is-the-new-html5#comment-42288 said that] on our blog.''

The specification text is kept in version control and not forgotten; in fact, version control archeology is often used as part of the spec's development to figure out when things changed, why they changed, and so forth. This is significantly more helpful than arbitrarily dated snapshots, which in practice aren't studied in the same way since they don't give as detailed an answer. With version control, you can narrow down changes to discussions that happened on a particular day or even hour, with snapshots you are often limited to a resolution of months or years, depending on how often you publish the snapshots.

You can see the version control repository for the WHATWG specifications at http://html5.org/tools/web-apps-tracker (Web interface) or http://svn.whatwg.org/webapps/ (SVN interface).
Every revision, however minor, is checked in separately. As of the time of this writing (January 2011), the repository has over 5700 revisions already.

(Another way of looking at it is that we have a new snapshot with every change! Publish early, publish often, as they say.)

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is the main focus of the WHATWG community. HTML5 is a snapshot of HTML, which is being worked on by the WHATWG community and also the W3C HTML Working Group.

HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec.

* The Twitter feed: http://twitter.com/WHATWG

* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.

* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.

* At a broader level, Anne is maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/

* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html

* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest

=== What are the various versions of the spec? ===

All active work at WHATWG is gathered in Web Applications 1.0. It is available as [http://www.whatwg.org/specs/web-apps/current-work/complete.html single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.

The WHATWG HTML standard is a subset containing only the HTML-specific material. It is available as [http://www.whatwg.org/specs/web-apps/current-work/ single-page]
and '''[http://whatwg.org/html multi-page]''', as well as in PDF [http://www.whatwg.org/specs/web-apps/current-work/html-a4.pdf A4] and
[http://www.whatwg.org/specs/web-apps/current-work/html-letter.pdf Letter].

The W3C HTML5 specification is a subset of the WHATWG HTML standard, containing only some of the more stable features.

The following table lists in the individual specifications included:

{| class="wikitable" border=1 cellpadding=3 cellspacing=0
|-
!
! WHATWG Specifications <br> (and sections therein)
! Section links for <br> [http://www.whatwg.org/specs/web-apps/current-work/complete/ Web Applications 1.0]
! W3C/IETF Specifications
|-
! HTML5 only (excluding newer features)
| n/a
| n/a
| [http://dev.w3.org/html5/spec/Overview.html Single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)
|-
! HTML (including newer features)
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
| Everything not listed below!
|
|-
! Microdata
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/microdata.html Microdata]
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)
|-
! Canvas 2D Context
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/the-canvas-element.html#2dcontext 2D Context]
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)
|-
! Communications - Cross-document messaging
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html#web-messaging Cross-document messaging]
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (HTML WG)
|-
! Communications - Channel messaging
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html#channel-messaging Channel messaging]
|-
! Web Workers
| [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers specification]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html Web Workers]
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)
|-
! Web Storage
| only in WA1
| [http://www.whatwg.org/specs/web-apps/current-work/complete/webstorage.html Web Storage]
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)
|-
! Web Sockets API
| only in WA1
| [http://www.whatwg.org/specs/web-apps/current-work/complete/network.html Web Sockets API]
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)
|-
! Server-Sent Events
| only in WA1
| [http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html#server-sent-events Server-sent Events]
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)
|-
! WebVTT
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#webvtt-0 In WHATWG HTML] and informally as [http://www.whatwg.org/specs/web-apps/current-work/webvtt.html WebVTT]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#webvtt-0 WebVTT]
|
|}

All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].

=== Are there versions of the specification aimed specifically at authors/implementors? ===

Not yet, but check back soon, we're working on this.

In the meantime, the WHATWG HTML specification (including the multipage version) can be customized to either hide or emphasize user-agent-specific material. The mode can be selected using radio buttons at the top right of those documents.

It is also possible to toggle the mode by changing the URL, here is an example for the multipage WHATWG HTML specification:

* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete
* Author view (hiding the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author
* Implementor view (highlighting the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.org/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/
* http://dev.opera.com/articles/html/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is no longer working specifically on HTML5, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback. (This state is not used often.)
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now. For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8 and is adding more to IE9.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

There are multiple problems with adding something like <di>:

* It would require parsing changes. These are relatively expensive.
* It would have a poor backwards-compatibility story until the parsers were all updated.
* It would have a poor backwards-compatibility story with legacy code that handles <dl>s, since they're not expecting <di>s.

The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.

(In the future, it is expected that the <time> element will be extended to support years and years+months, but this is awaiting implementation experience with what is already specified.)

=== <input type="text"> needs a minlength="" attribute ===

This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account — and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

The W3C HTML Working Group has an escalation process that in some cases results in a decision being made that differs from the editor's original decision on a topic. So far, whenever this has happened the WHATWG has gone along with the W3C's request; nothing of especially big importance has been changed in this manner so far (it's mostly been editorial issues or mostly minor technical issues). In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Mailing List ==

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous e-mails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

FAQ

2011-02-23T16:04:38Z

Oli: Removed html-5.com due to about page and suggested boilerplate (polyglot with XML namespace). Added HTML5Doctor, MDN and Opera [note: am H5D author]

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is the HTML standard. The WHATWG also works on Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events, and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== “Living specification” sounds like a draft that may and will change at any moment and is probably not even complete at any moment of time... ===

That's exactly what it is. However, the specification does not change arbitrarily: we are extremely careful! As parts of the specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compat unless for security reasons). The specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

You can see which parts of the spec are stable and which are not from the status annotations in the left margin.

=== Don’t browsers need a target to work their implementations towards, even if it’s a snapshot that is essentially arbitrary? ===

In practice, implementations all followed the latest specs draft anyway, not the latest snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.

=== When will it be safe to attempt to implement the spec based solely on the formal specification statements in the spec? ===

It's never truly safe; for example, if you tried to implement HTML4 according to the HTML4 specification you wouldn't have an implementation compatible with HTML4-era documents. However, if you're able to deal with minor changes, like security updates, errata-level changes, etc, then you can see which parts of the spec are stable and which are not from the status annotations in the left margin.

In general, though, we would strongly recommend taking part in the development effort. There's a [http://www.whatwg.org/mailing-list#imps mailing list for implementors] which can help.

=== How do we know what to use, without having some sort of snapshot that browsers can aim at and developers can evaluate? ===

The same way you do ''with'' snapshots. Browser vendors don't look at the last snapshot, they look at the ever-progressing latest text anyway.

No browser ever implemented all of HTML4, for example, even in the years after it was a formal Recommendation. Nor did they wait til they had done all of HTML3.2 before working on implementing HTML4. They all picked and chose the bits they thought were useful. With the Living Standard approach, we can also update the specification at the same time to remove the bits they all agree are useless, and to add new features that they think we should add (before they go off and invent their own solutions!).

=== Isn’t the whole point of a specification to establish fixed point of reference so that all parties implementing the standard can ensure they have a common baseline of compatibility? ===

No, the point of a specification is to provide an accurate description of what all the parties should implement. When an error is found in this description, it's better to fix it than to leave it.

HTML4 provides an example of this. HTML4 says the default value for the "media" attribute is "screen", even though it was long ago realised that this made no sense and the default should be "all". The browsers all implement it as "all". A snapshot with a known bug is not as useful as a living standard.

=== The large Web industry with many browsers and even more producers of web pages needs to evolve in reasonably consistent steps for ubiquity and interoperability, so we need snapshots ===

It's true that "the large Web industry with many
browsers and even more producers of web pages needs to evolve in
reasonably consistent steps for ubiquity and interoperability". However, unchanging snapshots of specifications
do nothing to help with this. The implementations usually follow the
drafts, not the snapshots, and in the exceptions where they don't, they
end up ''failing to interoperate''.

Consider what would happen if a Web browser vendor decided to implement
HTML4 instead of the latest state of the HTML Living Standard. That vendor would have <link>
elements with the wrong media="" attribute default, which would break
printing of most of the Web. That vendor would misparse <p><table>, which
would result in blank lines in numerous unexpected places. That vendor
would find that pages that styled empty paragraphs would fail to render as
expected. That vendor would find that millions of pages would be
unparseable due to not assuming a default encoding. That vendor would find
that 0.2% of pages were missing images due to HTML4 not requiring the
<image>/<img> aliasing. That vendor would, in short, find that the
spec was not an accurate description of the Web, and would either fail in
the market place (due to lack of interoperability), or would go seeking
the latest spec, the living standard, which would dramatically improve their interoperability
with legacy content and existing browsers.

Snapshots harm interoperability, they don't help it.

=== How about support in browsers for previous versions of this “living” HTML standard? ===

Browsers only need to implement the latest spec, and they will be compatible with the bulk of legacy content. That is an underlying principle of the entire WHATWG effort.

To clarify, browsers today don't implement separate modes for HTML2, HTML3.2, and HTML4. They just implement one version of HTML, and it works with everything (we call this "backwards compatibility"). This is the same model followed by the HTML specification; that's why it defines the browser requirements for lots of old features that aren't allowed anymore. For example, the "font" element is no longer conforming (authors aren't supposed to use it in their pages), but the spec still defines how it works, so that old pages keep working.

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this.

=== This means you will only able to add to a spec, not redefine it. ===

Yes. That's been a guiding principle for the WHATWG since its founding. It's even in our [http://www.whatwg.org/charter charter].

=== How can web developers know which features are safe to use? ===

See "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== Browsers can currently say they implement HTML 4.01 and most know what to expect. ===

Actually, that really isn't what happens in practice. Browsers do not implement specifications atomically, one spec at a time. They pick and chose features from the specs as they see fit. For example, back in the day, browsers implemented the absolute positioning parts of CSS2, but not 'display:run-in', but they still claimed to implement CSS2, and they already had parts of CSS3 implemented too, but not any part of a complete CSS3 module. Browsers claim to implement HTML4, but didn't implement all of it. Browsers moved on to HTML4 features before they had done all of HTML 3.2. And so on.

Plus, there's the problem of bugs. Different browsers have different bugs, and nothing in the spec's version can tell you what bugs the browser has.

Thus, in practice, you really can't tell what is implemented based on what version of what spec the vendor's marketing department claims to support. So not having a version number doesn't hurt. If anything, it helps, by removing a potentially bogus point of comparison — it means you have to compare browsers on what they really do (with a test suite), not on what version they claim to support.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week!

=== How will anything be deprecated and removed if there are no version numbers? ===

Not having version numbers doesn't stop us from removing features. We do that regularly, as described above in "[[FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F|Is there a process for removing bad ideas from a specification?]]". See also the "obsolete features" section in the HTML standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html

=== Will HTML become a bloated unimplementable mess as old features pile up if there are no version numbers? ===

No. We endeavour to not make HTML unimplementable — if it can't be implemented, there's not much point having a spec! Indeed, making HTML implementable is the main goal of the specification. Certainly HTML will continue to become complicated over time, but that is unrelated to whether we have version numbers or not.

=== Will HTML become an unusable mess as features are removed and old valid documents suddenly become invalid, if there are no version numbers? ===

No.

Features being invalid doesn't make them stop working — browsers are required to support old features. Even things like "inindex", framesets, "font", and so forth are still defined in the HTML specification, even though they're not to be used by authors. Old documents become invalid all the time, for example HTML 3.2 documents that use the "font" element were not valid HTML4 Strict documents, since it made "font" invalid (for good reasons, e.g. it tends to lead to authoring practices that harm accessibility). So even if we continue to make certain features invalid, it does not make HTML an "unusable mess".

=== If you do not publish snapshots every now and again, you are Orwellian in your recognition of the role the mistakes of the past play into the present and the future. ===

''No really, someone [http://blog.whatwg.org/html-is-the-new-html5#comment-42288 said that] on our blog.''

The specification text is kept in version control and not forgotten; in fact, version control archeology is often used as part of the spec's development to figure out when things changed, why they changed, and so forth. This is significantly more helpful than arbitrarily dated snapshots, which in practice aren't studied in the same way since they don't give as detailed an answer. With version control, you can narrow down changes to discussions that happened on a particular day or even hour, with snapshots you are often limited to a resolution of months or years, depending on how often you publish the snapshots.

You can see the version control repository for the WHATWG specifications at http://html5.org/tools/web-apps-tracker (Web interface) or http://svn.whatwg.org/webapps/ (SVN interface).
Every revision, however minor, is checked in separately. As of the time of this writing (January 2011), the repository has over 5700 revisions already.

(Another way of looking at it is that we have a new snapshot with every change! Publish early, publish often, as they say.)

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is the main focus of the WHATWG community. HTML5 is a snapshot of HTML, which is being worked on by the WHATWG community and also the W3C HTML Working Group.

HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec.

* The Twitter feed: http://twitter.com/WHATWG

* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.

* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.

* At a broader level, Anne is maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/

* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html

* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest

=== What are the various versions of the spec? ===

All active work at WHATWG is gathered in Web Applications 1.0. It is available as [http://www.whatwg.org/specs/web-apps/current-work/complete.html single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.

The WHATWG HTML standard is a subset containing only the HTML-specific material. It is available as [http://www.whatwg.org/specs/web-apps/current-work/ single-page]
and '''[http://whatwg.org/html multi-page]''', as well as in PDF [http://www.whatwg.org/specs/web-apps/current-work/html-a4.pdf A4] and
[http://www.whatwg.org/specs/web-apps/current-work/html-letter.pdf Letter].

The W3C HTML5 specification is a subset of the WHATWG HTML standard, containing only some of the more stable features.

The following table lists in the individual specifications included:

{| class="wikitable" border=1 cellpadding=3 cellspacing=0
|-
!
! WHATWG Specifications <br> (and sections therein)
! Section links for <br> Web Applications 1.0
! W3C/IETF Specifications
|-
! HTML5 only (excluding newer features)
| n/a
| n/a
| [http://dev.w3.org/html5/spec/Overview.html Single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)
|-
! HTML (including newer features)
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
| Everything not listed below!
|
|-
! Microdata
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/microdata.html Microdata]
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)
|-
! Canvas 2D Context
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/the-canvas-element.html#2dcontext 2D Context]
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)
|-
! Communications - Cross-document messaging
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html#web-messaging Cross-document messaging]
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (HTML WG)
|-
! Communications - Channel messaging
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html#channel-messaging Channel messaging]
|-
! Web Workers
| [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers specification]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html Web Workers]
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)
|-
! Web Storage
| only in WA1
| [http://www.whatwg.org/specs/web-apps/current-work/complete/webstorage.html Web Storage]
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)
|-
! Web Sockets API
| only in WA1
| [http://www.whatwg.org/specs/web-apps/current-work/complete/network.html Web Sockets API]
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)
|-
! Server-Sent Events
| only in WA1
| [http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html#server-sent-events Server-sent Events]
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)
|-
! WebVTT
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#webvtt-0 In WHATWG HTML] and informally as [http://www.whatwg.org/specs/web-apps/current-work/webvtt.html WebVTT]
| [http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#webvtt-0 WebVTT]
|
|}

All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].

=== Are there versions of the specification aimed specifically at authors/implementors? ===

Not yet, but check back soon, we're working on this.

In the meantime, the WHATWG HTML specification (including the multipage version) can be customized to either hide or emphasize user-agent-specific material. The mode can be selected using radio buttons at the top right of those documents.

It is also possible to toggle the mode by changing the URL, here is an example for the multipage WHATWG HTML specification:

* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete
* Author view (hiding the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author
* Implementor view (highlighting the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.org/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/
* http://dev.opera.com/articles/html/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is no longer working specifically on HTML5, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback. (This state is not used often.)
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now. For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8 and is adding more to IE9.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

There are multiple problems with adding something like <di>:

* It would require parsing changes. These are relatively expensive.
* It would have a poor backwards-compatibility story until the parsers were all updated.
* It would have a poor backwards-compatibility story with legacy code that handles <dl>s, since they're not expecting <di>s.

The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.

(In the future, it is expected that the <time> element will be extended to support years and years+months, but this is awaiting implementation experience with what is already specified.)

=== <input type="text"> needs a minlength="" attribute ===

This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account — and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

The W3C HTML Working Group has an escalation process that in some cases results in a decision being made that differs from the editor's original decision on a topic. So far, whenever this has happened the WHATWG has gone along with the W3C's request; nothing of especially big importance has been changed in this manner so far (it's mostly been editorial issues or mostly minor technical issues). In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Mailing List ==

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous e-mails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

Time element

2010-08-20T08:34:49Z

Oli: /* year month discussion */

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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)

=== 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]
* ...
</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 month only ==
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]
* 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)

=== 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]]
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.

Time element

2010-08-20T08:34:10Z

Oli: /* year month discussion */ adding various use cases

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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)

=== 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]
* ...
</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 month only ==
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]
* 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)

=== 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]]
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.

Time element

2010-08-20T08:29:56Z

Oli: /* year month use cases */ adding Japanese use case as per year example

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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)

=== 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]
* ...
</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 month only ==
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]
* 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)

=== 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.
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.

Time element

2010-08-20T08:27:57Z

Oli: /* year only discussion */ adding link

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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)

=== 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]
* ...
</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 month only ==
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]
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)

=== 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.
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.

Time element

2010-08-20T08:26:19Z

Oli: /* year only use cases */

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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)

=== 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).
* ...
</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 month only ==
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]
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)

=== 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.
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.

Time element

2010-08-20T08:25:36Z

Oli: /* year only discussion */ adding Japanese and future imprecise events use cases

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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年

=== 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).
* ...
</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 month only ==
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]
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)

=== 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.
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.

Time element

2010-08-20T08:17:59Z

Oli: /* year only use cases */ adding i18n example

Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].

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 ==
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]
*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年

=== 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.
* ...
</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 month only ==
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]
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)

=== 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.
* ...
</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 week only ==
The time element should accept just a year and a week number.
;ISO8601 syntax
:YYYY-WNN
;use case research
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.
:output equivalent of <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 ==
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"> - not supported in current time element
<input type="week"> - not supported in current time element
<input type="time"> - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year"> - not supported in current time element
<input type="month-day"> - not supported in current time element
</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 eras ("Edwardian", "bronze age", "Jurassic")".

;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)
* ...
</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.
* 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.
* …
</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 for reducing DRY violations =

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.
* +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 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 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)
* ...
</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.

= Minor editorial fixes =

== Update hCalendar example ==

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/proposals.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.