Current w3c draft HTML 5 spec for <time>:
http://dev.w3.org/html5/spec/text-level-semantics.html#the-time-element

A few things to consider in context of bug 19992 (using this to do localized time/datestamps using browser's client-side knowledge of user's timezone):

• if a 'datetime' attribute is present with the normalized timestamp, it's used as the date and/or time value -- thus the text contents may be freely formatted (or re-formatted)

• there's no standard for replacing visible times, so we'd probably want to use a class to mark localizable items

• the valueAsContent property doesn't distinguish between 'date only' and 'midnight UTC on that date', nor between 'time specified to the second at :00' and 'time specified to the minute'; could need to check the format or something to determine partial replacements

• note that applying timezone transformations to a UTC-midnight date timestamp may result in jumping off by a day depending on your local timezone -- probably not usually what's wanted.

• <time> will be theoretically relevant as metadata on things that you would probably not actually want to display localized in a user's timezone, for instance at https://en.wikipedia.org/wiki/JFK#Assassination:

"President Kennedy was assassinated in Dallas, Texas, at 12:30 pm [[Central Standard Time]] on November 22, 1963, ..."

this is relevant metadata and might be marked up something like:

"President Kennedy was assassinated in Dallas, Texas, at <time datetime='1963-11-22T12:30-06:00'>12:30 pm [[Central Standard Time]] on November 22, 1963</time>, ..."

meanwhile in UI and project coordination we're more likely to want to make them localizable:

"The IRC meeting will start at <time datetime='2011-11-25T12:00Z'>12:00 UTC on November 25</time>"

... but how will the system know we want to convert this one, and not the other one? Need a class? What about the contents? Would we lose that nice custom formatting there? Would we say 'too bad' and actually mark it up a little differently?

One possibility might be to have a wrapper parser function or template:

"The IRC meeting will start at {{#showtime:2011-11-25T12:00Z}}"

which might render to HTML:

"The IRC meeting will start at <time class='mw-showtime' datetime='2011-11-25T12:00Z'>2011-11-25 12:00 UTC</time>"

when then gets replacements done via JS into local time:

"The IRC meeting will start at <time class='mw-showtime' datetime='2011-11-25T12:00Z'>2011-11-25 04:00 PST</time>"

Code could emit the HTML w/ class markers directly when not going through wikitext...

Rather than a class maybe we should go for a data- param with some sort of format specifier. I don't doubt that people are going to be asking for "3 minutes ago" style timestamps as well as those formatted into a user's preferred time.

(In reply to comment #2)

Rather than a class maybe we should go for a data- param with some sort of
format specifier. I don't doubt that people are going to be asking for "3
minutes ago" style timestamps as well as those formatted into a user's
preferred time.

As for the format specifier, Just tell users to use the [[ISO 8601]] standard when entering time, What better solution than a standard?

(In reply to comment #3)

(In reply to comment #2)

Rather than a class maybe we should go for a data- param with some sort of
format specifier. I don't doubt that people are going to be asking for "3
minutes ago" style timestamps as well as those formatted into a user's
preferred time.

As for the format specifier, Just tell users to use the [[ISO 8601]] standard
when entering time, What better solution than a standard?

Not input format, output format. As in what format of time js should insert into the element.

For example protect-expiring(-local), instead of "expires $1 (UTC)" / "expires $1" could be something like: "expires <time data-format="relative" datetime="$4">$1 (UTC)</time>"

Which will end up with a js replacement ending up with something like "expires <time data-format="relative" datetime="2012-0-12T03:03:47Z">in 5 minutes</time>".

Note that I added support for <data>, <time>, <meta>, and <link> (missing elements of Microdata) in WikiText in r111891.

Still need formatting code, parser function, etc... of course.

Change was backed out of svn for the git migration, new gerrit changeset:
https://gerrit.wikimedia.org/r/#change,4251

(In reply to comment #7)

https://gerrit.wikimedia.org/r/#change,4251

Patch was merged in November 2012.

As written in comment 6,

Still need formatting code, parser function, etc... of course.

According to the support chart (as of 2016-02-22) in T25932: Allow use of semantic HTML5 elements in wikitext it is already supported. Could this task be closed then?