Last modified: 2007-07-12 15:24:57 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 T10577, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8577 - strange double-counting with wgLocaltimezone and weekday in signatures
strange double-counting with wgLocaltimezone and weekday in signatures
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
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: ---


Attachments

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.


Navigation
Links