MediaWiki should support <time> in WikiText
OpenPublic

Description

html5 has a <time> element. It carries the semantics noting that the contents are a date, and if the contents aren't in a set of machine readable formats there is a datetime="" attribute that can contain a machine readable format.
So eg: <time datetime="2011-11-12T14:54Z">November 12, 2011 6:54 PST</time> displays the date in a human readable format in PST while also noting the date in a machine readable time format.

It's possible some user agents may add support for functionality that takes advantage of these semantics. For example they may provide a display of the time in the user's current timezone. <time> is also used in some microdata formats iirc

pubdate seams to have been removed from <time>. Even if it's added back we probably should strip it out of WikiText since inline text shouldn't be able to define what looks externally to be authoritative information about the entire page that MW defined.

We should permit the use of <time> inside WikiText.


Version: 1.21.x
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=19992

bzimport added projects: MediaWiki-Parser, I18n.Via ConduitNov 22 2014, 12:03 AM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz32545.
DanielFriesen created this task.Via LegacyNov 21 2011, 12:11 PM
brion added a comment.Via ConduitNov 22 2011, 1:34 AM

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.

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

DanielFriesen added a comment.Via ConduitFeb 19 2012, 2:05 AM

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.

Peachey88 added a comment.Via ConduitFeb 19 2012, 2:14 AM

(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?

DanielFriesen added a comment.Via ConduitFeb 19 2012, 3:03 AM

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

DanielFriesen added a comment.Via ConduitFeb 19 2012, 3:28 AM

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

DanielFriesen added a comment.Via ConduitFeb 20 2012, 4:12 AM

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.

DanielFriesen added a comment.Via ConduitApr 4 2012, 7:03 AM

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

Aklapper added a comment.Via ConduitMar 22 2013, 2:18 PM

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

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.