Page MenuHomePhabricator

function userAdjust() handles system time zone incorrectly ({{REVISIONTIMESTAMP}} for other times of year wrong)
Open, LowPublicFeature

Description

function userAdjust() in Language.php handled user time zone not correct. This affect time zone with clock shifts, for example "Europe/Berlin".

For example: in summer the winter time is not corrected displayed (and the other way round).

set the time zone in preferences to "Europe/Berlin" (on de.wp). For logged out user and the option 'server default' the time is correct!

After setting the preferences:
the header of version http://de.wikipedia.org/w/index.php?oldid=52264210 show 14:01, 26. Okt. 2008, the included REVISIONTIMESTAMP says 20081026150115 (that was after clock shifts, winter time has an offset from 1 hour to the current summer time) => not equal, offset from 1 hour

the header of version http://de.wikipedia.org/w/index.php?oldid=52230987 show 18:14, 25. Okt. 2008 (summer time, same as current time), REVISIONTIMESTAMP says 20081025181428 => equal

A solution can be: Use wfTimestamp( current user timezone, $date ) to create the adjust time. Use wfTimestamp( TS_MW, $date ) to adjust the server default. Use mktime() if the offset is specify by user.

I am not so familiar with php and mediawiki, so I cannot give you a patch, only this description and idea. I hope, I am on the right lines with it. Thanks.


Version: unspecified
Severity: enhancement
URL: http://de.wikipedia.org/w/index.php?title=Hilfe:Variablen&offset=20081027000000&action=history&limit=2

Details

Reference
bz19516

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:43 PM
bzimport set Reference to bz19516.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 7249
untested patch

I have attached a untested patch to show what I mean.

attachment bug19516.patch ignored as obsolete

I have created testpages:

When looking now at summertime, you will see that REVISIONTIMESTAMP and LOCALTIMESTAMP are not the same (differ by one hour).

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

Ahh I think I see what's happening. The headers etc which use the user setting are showing correctly -- it's the {{REVISIONTIMESTAMP}} that renders wrong.

{{REVISIONTIMESTAMP}} uses the server-wide timezone setting, which looks like it's getting incorrectly set still through an old old system which only grabs the current offset -- so at the moment we're actually using '120 minutes offset' instead of 'Europe/Berlin' as the server default. D'oh!

Edited after end of summer time:
http://de.wikipedia.org/w/index.php?oldid=52264210 shows:
• header UTC: 2008-10-26 um 13:01:15
• header set to Europe/Berlin: 2008-10-26 um 14:01:15 <- +1 RIGHT
• REVISIONTIMESTAMP: 20081026150115 <- +2 WRONG

Edited during summer time:
http://de.wikipedia.org/w/index.php?oldid=52230987 shows:
• header UTC: 2008-10-25 um 16:14:28
• header set to Europe/Berlin: 2008-10-25 um 18:14:28 <- +2 RIGHT
• REVISIONTIMESTAMP: 20081025181428 <- +2 RIGHT

This bit in CommonSettings.php needs to be removed:

if ( !isset( $wgLocaltimezone ) ) $wgLocaltimezone = 'UTC';

Ugly hack warning! This needs smoothing out.

if ( $wgLocaltimezone ) {

$oldtz = getenv( 'TZ' );
putenv( "TZ=$wgLocaltimezone" );
$wgLocalTZoffset = date( 'Z' ) / 60;
putenv( "TZ=$oldtz" );

}

... and alas similar code appears to be in Setup.php now. :P

Language::userAdjust's path through 'System' or tz being '' should probably be pulled up and run through the date_create / date_timezone_set stuff if $wgLocaltimezone is set, preferable to $wgLocalTZOffset.

Or at least they need to be sorted out in some way. :P

sumanah wrote:

Umherirrender, I am sorry to say that your patch no longer applies cleanly to trunk. Could you possibly update it and resubmit? Thank you!

(In reply to comment #5)

Umherirrender, I am sorry to say that your patch no longer applies cleanly to
trunk. Could you possibly update it and resubmit? Thank you!

No, I am not very familar with php and its date/time function. I have created that patch only to show the problem better, not as solution.

Please mark the patch as obsolete.

bug 32297 seems a way in the right way.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM