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 (https://github.com/moment/moment) 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. :)

See T107892: Prompt user to change time zone preference if it differs from browser/OS time. for a slightly different approach to the time zone part of this.

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:
https://github.com/date-fns/date-fns

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