Page MenuHomePhabricator

Stop using putenv() for TZ var, use date_default_timezone_set()
Closed, ResolvedPublic

Description

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 !


Version: 1.5.x
Severity: normal

Details

Reference
bz2658

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:37 PM
bzimport set Reference to bz2658.
bzimport added a subscriber: Unknown Object (MLST).

jeluf wrote:

*** 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)

  1. 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. ***

niels.olson wrote:

just leaving a note that this bug is still in the trunk Preferences.php.