Page MenuHomePhabricator

Support client-side date/time formatting for user's timezone, language, and preferred format (JavaScript)
Open, LowPublicFeature


This could be the ultimate in sensible default behavior, and could work for anons as well as logged in folks.

JavaScript running in the browser has access to the computer's local time zone information, and could perform runtime conversion and local formatting. A <noscript> fallback can provide current defaults.

Issues to consider:

document.write inline vs Dom manipulation -- compat, purity, display/flicker issues?

Formatting and localization -- we have a lot of date and time formatting options, including alternate calendars. Do we need to replicate all of these in JS code or can we get away with just the default -- assuming any other option would force server-side rendering?

Date headers in lists such as RecentChanges will move depending on the timezone.

Can we handle talk page sigs? (or leave that to LQT?)

How should we mark timezone on output to indicate to the user what he/she is looking at?

Version: unspecified
Severity: enhancement
See Also:



Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:42 PM
bzimport set Reference to bz19992.
bzimport added a subscriber: Unknown Object (MLST).

One more note -- can we handle DST correctly this way? Times should be adjusted for the local offset in place on their dates, not dependent on whether we're in dst or not at the time we view it. (in which case we also need clear tz marking so you can distinguish the overlap zones where there's two 2ams in a row. )

Some answers to my older questions to self:

  • avoid document.write; we are a DOM world now, and jQuery simplifies out some of the browser-specific oddities like text vs textContent
  • various formatting & localization stuff is getting merged into the JS side these days, so we should make sure this is handled in some consistent-ish way
  • talk page signature should probably start marking up times in a machine-readable way so we can reformat those
  • DST stuff appears to be handled correctly; the browser's JS engine will hook into some system locale library that has all the timezone info, so it should do conversions from UTC to local time using the appropriate mode for the date the time is attached to, as long as both bits of info are there. Confirmed that Date.getTimezoneOffset() returns the offset for the target date, not the current date.

The actual markup is still an open issue... one possibility is to use a data attribute:

<span class="mw-ts" data-mw-datetime="20110606220634">6 June 2011 22:06:34</span>

or for just date or just time:

<span class="mw-ts" data-mw-time="20110606220634">22:06:34</span>
<span class="mw-ts" data-mw-date="20110606220634">6 June 2011</span>

With JS off, whatever the original form was goes through intact. With JS on, our handlers zip on through finding the matching ones and reformatting them.

Couple issues:

  • as noted above, lists with date headings like RecentChanges will need special handling, since day boundaries move.
  • the in-browser JS APIs don't expose a symbolic name for the timezone -- we can get an offset, though, so can display like '15:06:34 (UTC-7)' though we perhaps can't reliably display '15:06:34 (PDT)'.
  • 'flicker' can be a problem with post-processing of timestamps; slow page loads may leave a delay between the start of the document being visible and loading & execution of code at end. Possibly we can get away with an early start for the time formatting, but access to locale info is very useful for this...

For the output, I think we should make use of html5's <time> element. It has the semantics for this, it's got a datetime="" attribute for the machine readable format, and it was pretty much invented for precisely this kind of purpose. (Well that, and maybe also letting JS create a countdown to that time)

Relevant bug 32545. I added it as a dependency.
The easiest way to start this is probably to add support for <time> to WikiText. Then implement client side scripts that do things to <time>. And then start adding special WikiText syntaxes for signatures and other special cases we have.

  • Bug 34727 has been marked as a duplicate of this bug. ***

As more and more MediaWiki interfaces are being constructed dynamically on the client-side, we really need to implement a solution for this. Not only for timezone, but also for preferred date format and language (for logged in users). Siebrand says the i18n team is aware of the issue and hoping to work on it some time in the near future (possibly with Timo's assistance).

Removed 32545 as a blocker. It is a related bug, but not a blocker.

This should be easier now that momentjs ( is available in core.

As a result of touring, I have been changing the time zone in preferences .... Said to self "Why isn't there a choice of "Get it from the OS?".

I think the priority should be raised!

Regards, Richard.

Raising priority itself doesn't fix an issue; somebody providing a patch would help. :)

I incorporated the <time> and Moment.js ideas into a rewrite of the CommentsInLocalTime user script that’s now installed at the Vietnamese wikis.

There is no need in new format data-mw-datetime="20110606220634" - we can use ISO 8601 / Unix time / JD
There can be need in some stringFormat parameter instead only date/time/datetime.

I'm going to solve this problem on the server side now. However, on the client side, in the case of displaying dates, say, in different calendars, it can be convenient to have a gadget for this that would display all dates in either the Julian or Gregorian calendar. There are also many other calendars, those that are actually used, for example, the Hebrew, would also be good to maintain.

the javascript libary date-fms looks kind of nice to address the data formatting challenge:

@ThurnerRupert As mentioned above, Moment.js, another date-handling library, is already shipped with MW core. The problem isn't that there isn't a nice way to format or parse dates, but that there isn't a nice way to format or parse dates in the format the user sees in the MW interface without a lot of reinventing the wheel.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM