Bug 521685 - date(): It is not safe to rely on the system's timezone settings
Summary: date(): It is not safe to rely on the system's timezone settings
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F12Target
TreeView+ depends on / blocked
 
Reported: 2009-09-07 17:43 UTC by Nicolas Mailhot
Modified: 2009-10-08 07:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-08 07:13:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nicolas Mailhot 2009-09-07 17:43:57 UTC
Description of problem:

Apache error logs are overflowing with

[error] [client ] PHP Warning:  date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /usr/share/squirrelmail/src/left_main.php on line 388, referer: https:///src/webmail.php


Version-Release number of selected component (if applicable):
squirrelmail-1.4.20-0.rc2.fc12.noarch

Comment 1 Tomas 2009-09-12 06:30:05 UTC
You have increased error logging. I think this error is from E_DEPRECATED or E_STRICT level. SquirrelMail is designed to run on PHP 4.1.2 and later. Features reported in this error are available only in PHP 5.1.0+.

Comment 2 Michal Hlavinka 2009-10-07 12:34:14 UTC
Hi Tomas, thanks for the information.

Nicolas:

I've been talking with php maintainer and 

> You are *required* to use the date.timezone setting or ...

this is exactly what you should do: set date.timezone in your php.ini

I can confirm that when date.timezone in /etc/php.ini is set, this problem goes away.

Comment 3 Nicolas Mailhot 2009-10-07 13:15:35 UTC
I'm sorry but I totally disagree.

It is not safe to multiply the date tuneables all over the place. The more complexity you add admin-side the more likely it is someone will forget one of them.

By all means allow php to override the system date for people unlucky enough to deploy on a misconfigured server. But people deploying on a clean server (that should be the general case, not the exception) should not have to re-specify date settings at the php level

Comment 4 Tomas 2009-10-07 13:34:30 UTC
SquirrelMail 1.5.x has updated timezone handing code. Some updates set timezone with PHP functions, but code still has to suppress similar error notice, if SquirrelMail wants to use server's timezone. Updated code proves that listening to PHP E_STRICT notices leads to broken programming. In some setups code can fail with fatal error, because PHP developers made their usual anti-Turkish i18n programming mistakes in timezone code. You are free to ask SquirrelMail devels to port that code to 1.4.x. Porting does not require complete rewrite of timezone handling.

Please reduce your error reporting level. SquirrelMail WAS written to work in E_ALL error reporting code and it worked fine until PHP devels decided to push their backwards incompatible coding practices in E_STRICT and E_DEPRECATED error levels.

Comment 5 Michal Hlavinka 2009-10-07 13:39:15 UTC
This behaviour is caused by php change. This change was intentional php's
upstream decision, if you want default configuration in php to be changed, feel free to open new bug against php or change component to php in this bug together with comment what change you require, I'll close this bug otherwise.

Comment 6 Joe Orton 2009-10-07 20:23:03 UTC
You need to specify precisely what you expect to change in PHP if you reassign this to PHP.

Comment 7 Nicolas Mailhot 2009-10-07 21:16:55 UTC
(In reply to comment #6)
> You need to specify precisely what you expect to change in PHP if you reassign
> this to PHP.  

see comment #3

Comment 8 Joe Orton 2009-10-08 07:13:39 UTC
Per the comment Michal relayed, this is how upstream designed and intends PHP to work - you must explicitly configure the timezone setting.


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