Last modified: 2007-07-12 15:24:57 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 8577 - strange double-counting with wgLocaltimezone and weekday in signatures
strange double-counting with wgLocaltimezone and weekday in signatures
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
PC Linux
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 9325
  Show dependency treegraph
Reported: 2007-01-11 12:00 UTC by Zhen Lin
Modified: 2007-07-12 15:24 UTC (History)
0 users

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


Description Zhen Lin 2007-01-11 12:00:43 UTC
When $wgLocaltimezone is a large number (i.e. > 6 or < -6), the day of week
which appears in signatures can be off by ±1 day. For example, today at 10:45AM
UTC, Pacific/Honolulu was Wednesday, Europe/France was Thursday, and Asia/Tokyo
was Friday. It appears to result from applying the timezone correction twice,
but I cannot be certain. The date and time is completely unaffected, and the
magic words ({{CURRENTDAYNAME}}  etc.) report the correct day of week.

To replicate, set the system time to UTC), and set $wgLocaltimezone to somewhere
near the international dateline (Pacific/Auckland is good, so is
Pacific/Honolulu). Set $wgLanguageCode to ja or another language which includes
the day of the week in the signature.
Comment 1 Zhen Lin 2007-02-25 06:52:18 UTC
I think I've identified the problem. This affects everything in sprintfDate
which calculates using a UNIX timestamp. There are two possible ways to fix it.

First option: move the call to timeanddate() in Parser.php out of the scope
where TZ is altered:

if ( isset( $wgLocaltimezone ) ) {
	$oldtz = getenv( 'TZ' );
	putenv( 'TZ='.$wgLocaltimezone );
$timestamp = date( 'YmdHis' );
if ( isset( $wgLocaltimezone ) ) {
	putenv( 'TZ='.$oldtz );
$d = $wgContLang->timeanddate( $timestamp , false, false) .
  ' (' . date( 'T' ) . ')';

Alternatively, change the calls to date() in Language.php to gmdate(). I'm not
sure which one is more correct, since it isn't stated anywhere whether
sprintfDate() takes UTC timestamp and formats it in accordance to the TZ
environment variable, or if it takes any timestamp and does no timezone adjustment.
Comment 2 Brion Vibber 2007-06-15 19:08:34 UTC
Fixed, I hope, in r23017.

{{CURRENT*}} functions now consistently use UTC as intended, while
{{LOCAL*}} functions return local time per server config or $wgLocaltimezone.

Signature dates for Japanese and other languages including weekday now show
the correct day to match the rest of the time in local time.

Previously there was a weird mix, where {{CURRENT*}} sometimes used server local time while {{LOCAL*}} used $wgLocaltimezone, and sometimes either were just borked.

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