Last modified: 2014-03-03 20:42:26 UTC
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.
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.
