Last modified: 2014-08-13 18:39:15 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 19992 - Support client-side date/time formatting for user's timezone, language, and preferred format (JavaScript)
Support client-side date/time formatting for user's timezone, language, and p...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
Depends on:
Blocks: 5347 29235 30672 30857 38079 29289
  Show dependency treegraph
 
Reported: 2009-07-29 15:46 UTC by Brion Vibber
Modified: 2014-08-13 18:39 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2009-07-29 15:46:43 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?
Comment 1 Brion Vibber 2009-07-29 15:50:10 UTC
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. )
Comment 2 Brion Vibber 2011-06-06 22:24:37 UTC
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...
Comment 3 Daniel Friesen 2011-11-21 12:16:12 UTC
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.
Comment 4 Mark A. Hershberger 2012-02-26 21:07:04 UTC
*** Bug 34727 has been marked as a duplicate of this bug. ***
Comment 5 Ryan Kaldari 2012-09-19 21:43:23 UTC
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).
Comment 6 Ryan Kaldari 2012-09-19 21:49:56 UTC
Removed 32545 as a blocker. It is a related bug, but not a blocker.
Comment 7 Kunal Mehta (Legoktm) 2014-06-05 04:23:00 UTC
This should be easier now that momentjs (https://github.com/moment/moment) is available in core.
Comment 8 Richard Ames 2014-06-12 21:11:37 UTC
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.
Comment 9 Andre Klapper 2014-06-12 21:57:10 UTC
Raising priority itself doesn't fix an issue; somebody providing a patch would help. :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links