Last modified: 2010-05-15 15:37:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2658 - Stop using putenv() for TZ var, use date_default_timezone_set()
Stop using putenv() for TZ var, use date_default_timezone_set()
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.5.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 2668 7715 14290 (view as bug list)
Depends on: 7715
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-01 22:22 UTC by T. Gries
Modified: 2010-05-15 15:37 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description T. Gries 2005-07-01 22:22:43 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 !
Comment 1 T. Gries 2005-07-02 11:24:11 UTC
( A duplicate has been filed as http://bugzilla.wikimedia.org/show_bug.cgi?id=2668 )
Comment 2 JeLuF 2005-07-02 11:56:55 UTC
*** Bug 2668 has been marked as a duplicate of this bug. ***
Comment 3 T. Gries 2005-07-02 12:15:00 UTC
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()
Comment 4 T. Gries 2005-07-02 13:46:36 UTC
(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.
Comment 5 Brion Vibber 2005-07-03 02:14:10 UTC
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)
Comment 6 T. Gries 2005-07-05 21:24:22 UTC
(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.,
Comment 7 Brion Vibber 2005-07-05 21:43:23 UTC
That's not this bug, and it should do the exact sme thing on earlier MediaWiki versions since the same code is there.
Comment 8 T. Gries 2005-07-07 19:46:04 UTC
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
Comment 9 T. Gries 2005-07-07 19:51:18 UTC
changed title, because the problem is another one
Comment 10 T. Gries 2005-07-07 19:53:07 UTC
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.
Comment 11 Ilmari Karonen 2008-02-09 20:46:00 UTC
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).
Comment 12 Chad H. 2009-07-24 19:23:00 UTC
*** Bug 7715 has been marked as a duplicate of this bug. ***
Comment 13 Shinjiman 2009-07-25 07:31:55 UTC
The issue mentioned in the bug 7715 now throws E_WARNING instead of E_STRICT as of PHP 5.3.0.
Comment 14 Chad H. 2009-07-30 13:45:40 UTC
*** Bug 14290 has been marked as a duplicate of this bug. ***
Comment 15 Niels Olson 2009-08-31 00:02:57 UTC
just leaving a note that this bug is still in the trunk Preferences.php. 
Comment 16 Tim Starling 2010-01-08 02:09:42 UTC
Fixed in r60825.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links