Last modified: 2014-08-13 18:39:15 UTC
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?
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. :)
