Last modified: 2014-09-24 00:05:24 UTC
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.
Created attachment 7249 [details] untested patch I have attached a untested patch to show what I mean.
I have created testpages: * Summertime: ** URL: http://de.wikipedia.org/w/index.php?oldid=80378354 ** REVISIONTIMESTAMP: 20101017135817 ** LOCALTIMESTAMP: 20101017145817 ** UTC-Timestamp of Revision: 2010-10-17T12:58:17Z * Wintertime: ** URL: http://de.wikipedia.org/w/index.php?oldid=80927014 ** REVISIONTIMESTAMP: 20101031075756 ** LOCALTIMESTAMP: 20101031075756 ** UTC-Timestamp of Revision: 2010-10-31T06:57:56Z 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
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.