Last modified: 2013-11-15 11:05:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35454, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33454 - Timestamp in timel should mark its timezone: Add a timezone parameter to Language::sprintfDate()
Timestamp in timel should mark its timezone: Add a timezone parameter to Lang...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Brad Jorsch
: platformeng
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-01 11:52 UTC by Woojin Kim
Modified: 2013-11-15 11:05 UTC (History)
5 users (show)

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


Attachments

Description Woojin Kim 2012-01-01 11:52:01 UTC
{{#timel:c}} in Korean Wikipedia (using KST - UTC+09) produces:
* 2012-01-01T20:31:03+00:00
It should be 20:31 in Seoul, but server assumes it is 20:31 in London. It should be fixed to "2012-01-01T20:31:03+09:00. Furthermore, {{#timel:o-W}} produces 2012-52 (wrong), but {{#time:o-W}} prints 2011-52 (correct, but timezone is ignored).

Please fix this issue. Thanks.
Tested at 2012-01-01T20:31+09:00.
Comment 1 Mark A. Hershberger 2012-01-02 02:25:25 UTC
From [[mw:Help:Extension:ParserFunctions]], "c" is defined as:

  ISO 8601 formatted date, equivalent to Y-m-dTH:i:s+00:00.

Since the timezone is specified for "c", you are seeing the correct output.

Of course, http://php.net/strftime says that "%c" is

  Preferred date and time stamp based on local[e]

And the Linux manpage for strftime (http://linux.die.net/man/3/strftime) says:

  The preferred date and time representation for the current locale.

Berkely manpages (http://compute.cnr.berkeley.edu/cgi-bin/man-cgi?strftime+3) offers a little more information:

  Locale's appropriate date and time represented as:

  %a %b %d %H:%M:%S %Y

  This is the defaut behavior as  well  as  standard-
  conforming  behavior  for standards first supported
  by releases prior to Solaris 2.4. See standards(5).

So, yes, the mw implementation appears to be wrong.
Comment 2 Bawolff (Brian Wolff) 2012-01-02 08:21:31 UTC
hmm, whats a non-hacky way of fixing this. The obvious way is to pass some sort of timezone offset as third parameter to sprintfDate, and then cut off the last 5 characters of gmdate( 'c', $unix ) and replace it with the time zone offset. But that's icky... I guess should construct 'c' from its constituent parts...

If we do fix this we should consider adding a new formatting character to get the timezone offset (+05:00) and timezone name (MST, ADT, etc). There's probably certain circumstances where that would be useful


>Furthermore, {{#timel:o-W}} produces 2012-52 (wrong)

There was a bug in the code where 'o' had the timezone adjusted twice (So it was 18 hours ahead, instead of 9 hours - thus putting it in 2012 when it still should of been in 2011). None of the other formatting characters had this issue. This should be fixed as of r107806 (of course we won't see the issue again until next new years)
Comment 3 Tim Starling 2012-04-23 22:34:58 UTC
I think adding a timezone parameter to Language::sprintfDate() is the appropriate way to go about it. Then instead of gmdate(), we could use "new DateTime()", which accepts a timezone parameter, and the format() method to format it. The "c" format specifier in PHP does support timezones other than UTC, if it's called in the correct way.
Comment 4 Brad Jorsch 2013-03-22 17:03:39 UTC
I also note that {{#timel:}} returns the wrong thing for 'r' and 'U'.

Gerrit change #55274 to core adds the parameter to Language::sprintfDate()
Gerrit change #55275 uses this parameter in ParserFunctions.
Gerrit change #55276 uses this parameter in Scribunto.
Comment 5 Gerrit Notification Bot 2013-04-09 23:23:08 UTC
https://gerrit.wikimedia.org/r/55274 (Gerrit Change Iea1f78428bc0d32d6395818311dbe4b94d776c42) | change APPROVED and MERGED [by jenkins-bot]
Comment 6 Technical 13 2013-04-21 14:40:34 UTC
Not sure this is working as intended, but hard to tell because the documentation on it is very slim.  See http://www.mediawiki.org/wiki/User:Technical_13/SandBox for what I expected it to output. Basically, I expected it to output the local timezone and not the server or UTC...  It is currently only outputting UTC and I see no benefit to that.
Comment 7 Bawolff (Brian Wolff) 2013-04-21 17:40:12 UTC
(In reply to comment #6)
> Not sure this is working as intended, but hard to tell because the
> documentation on it is very slim.  See
> http://www.mediawiki.org/wiki/User:Technical_13/SandBox for what I expected
> it
> to output. Basically, I expected it to output the local timezone and not the
> server or UTC...  It is currently only outputting UTC and I see no benefit to
> that.

Yeah sorry, we have multiple definitions of "local" timezone. Timel outputs the server time where time always outputs utc. Most wikimedia projects (including mw.org) use utc as server time. Some exceptions are korean, and german. Basically timel outputs the same timezone as what ~~~~~ outputs.
Comment 8 Gerrit Notification Bot 2013-11-14 15:18:48 UTC
Change 95390 had a related patch set uploaded by MarkAHershberger:
Add timezone support to mw.lang:formatDate

https://gerrit.wikimedia.org/r/95390
Comment 9 Gerrit Notification Bot 2013-11-14 15:21:48 UTC
Change 95390 merged by MarkAHershberger:
Add timezone support to mw.lang:formatDate

https://gerrit.wikimedia.org/r/95390
Comment 10 Andre Klapper 2013-11-15 11:05:01 UTC
No open patches to review here (backport patch for REL_1_21 got merged), hence restting status to RESOLVED FIXED.

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


Navigation
Links