Last modified: 2010-05-15 15:37:44 UTC
Having $wgLocaltimezone = false it is assumed that the signature comes in a standard time (afaik: UTC, server independent) and a timezone indicator is added. But the trailing string stems from the server's environment, on my machine "CEST", which is user preferenced offset (in my case, 2 hours). This renders any signature as "....... (CEST)", the time correctly shown as UTC, but the string being wrong. When I fake $wgLocaltimezone = "UTC" in DefaultSettings.php, this corrects my problem, but studying the code in Parser:pstPass2 I feel that the parser is not fully correctly programmed there and should perhaps _not_ use $wgContLang and date( 'T' ) there. I am not sure, and one of you experts should have a look into this problem. It is only referring to the rendering of the timestamps on signatures !
( A duplicate has been filed as http://bugzilla.wikimedia.org/show_bug.cgi?id=2668 )
*** Bug 2668 has been marked as a duplicate of this bug. ***
update: according to JeLuF, local Wikipedias like the German dewiki (= de.wikipedia.org) _shall_ show timestamps in their localtime (currently CEST) with "(CEST)" as indicator for that. This means for dewiki: that further investigation is needed why the _time_ on signatures is not correctly shown, whereas the string (CEST) is correct. see module Parser.php, function pstPass2()
(In reply to comment #7 if bugzilla 2668 = duplicate of 2658) > ... But the large marioty of user of the German Wikipedia are in > Central Europe. So this timezone should be used. I fully understand. Your argumentation gives also support for my patch http://bugzilla.wikimedia.org/show_bug.cgi?id=505 for non-global wikis, where $wgTimezoneoffsetOverwrite is introduced. Using this, a WikiSysop can switch all time indications in the whole wiki to have a certain timeoffset. For Wikis running Mid European Time, this currently needs two adaptations per year, $wgTimezoneoffsetOverwrite='01:00' (November - March) $wgTimezoneoffsetOverwrite= '02:00' (April-October). The single user wouldn't have to adapt his/her user preferences any longer. The variable was introduced as an ad-hoc fix. Until October 2005, I plan to have a final solution for the '505 problem, namely to have an automatic time offset correction based on a user TIMEZONE identifier; once entered into user preferences, the wiki knows, where you are located and switches all time inidcations for you to your preferred local time, e.g. "Gesetzliche Zeit in Deutschland" (MEZ/CET or MESZ/CEST). The '505-patch is part of my EnotifWiki (special edition of MediaWiki), see http://meta.wikipedia.org/wiki/Enotif and http://sourceforge.net/projects/enotifwiki . Thus, any Sysop running EnotifWiki can switch the whole wiki into (e.g.) UTC+2 mode; in this case, user preferences show a message "offset: 02:00 (fixed)". If the Sysop sets $wgTimezomecorrectionOverwrite=false; the wiki behaves like standard MediaWiki.
The local time date() call had gotten replaced by a wfTimestamp(), which always returns UTC (using gmdate()). I've put it back, and it seems to be workiing correctly now (as reported on nl.wikipedia.org)
(In reply to comment #5) > The local time date() call had gotten replaced by a wfTimestamp(), which always > returns UTC (using gmdate()). I've put it back, and it seems to be workiing > correctly now (as reported on nl.wikipedia.org) Brion, sorry to need to tell you this: a user (apparently with PHP SAFE MODE) has reported to me: If I want to 'Show preview' in the 'Edit'-Modus Warning: putenv(): Safe Mode warning: Cannot set environment variable 'TZ' - it's not in the allowed list in /srv/www/htdocs/web3/html/wiki/includes/Parser.php on line 2851 Warning: putenv(): Safe Mode warning: Cannot set environment variable 'TZ' - it's not in the allowed list in /srv/www/htdocs/web3/html/wiki/includes/Parser.php on line 2862</pre> This error did not show up in pre-beta2 versions.,
That's not this bug, and it should do the exact sme thing on earlier MediaWiki versions since the same code is there.
Brion, I am happy to found the underlying problem for this after thoroughly studying it. Please apologise for provisionally reopening this bugzilla, because I think that this can be relevant for the 1.5 final release (but I am not sure; pls. close otherwise silently ;-) The reason was that those conditions came incidentially together: 0) server runs (apparently) in CEST timezone 1) the user had set $wgLocaltimezone = 'UTC'; (to fix the beta1/2 bug with the signature timestamp, as you know) 2) the user works in PHP SAFE MODE environment, which he cannot change 0 && 1 && 2 ==> interfered in Parser.php when the putenv() command was issued ('CEST' server != 'UTC' user) because putenv() appears to be forbidden in PHP SAFE MODE 1) makes now evident, why the problem wasn't seen BEFORE beta1/2: because nobody has touched the $wgLocaltimezone swithc before. I personally do not "live" in such an environment, but perhaps you want to make MediaWiki working there too, then a solution must probably found or the commenting texts in DefaultSettings.php should be amended with an additional remark, that $wgLocaltimezone may not be changed to any other value than null in PHP SAFE MODE environment. Tom
changed title, because the problem is another one
This message can be seen under these conditions: "Warning: putenv(): Safe Mode warning: Cannot set environment variable 'TZ' - it's not in the allowed list Parser.php on line 2851" 1) PHP SAFE MODE and 2) $wgLocaltimezone <> null (in DefaultSettings.php) when clicking SHOW PREVIEW.
In PHP 5.1.0 and above, we should be using date_default_timezone_set() instead of setting the TZ environment variable; I assume that would work even in safe mode. As for the original signature bug, I've hopefully just fixed that (see bug 12815).
*** Bug 7715 has been marked as a duplicate of this bug. ***
The issue mentioned in the bug 7715 now throws E_WARNING instead of E_STRICT as of PHP 5.3.0.
*** Bug 14290 has been marked as a duplicate of this bug. ***
just leaving a note that this bug is still in the trunk Preferences.php.
Fixed in r60825.
