Bug 521685 - date(): It is not safe to rely on the system's timezone settings
date(): It is not safe to rely on the system's timezone settings
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F12Target
  Show dependency treegraph
Reported: 2009-09-07 13:43 EDT by Nicolas Mailhot
Modified: 2009-10-08 03:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-08 03:13:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2009-09-07 13:43:57 EDT
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):
Comment 1 Tomas 2009-09-12 02:30:05 EDT
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 08:34:14 EDT
Hi Tomas, thanks for the information.


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 09:15:35 EDT
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 09:34:30 EDT
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 09:39:15 EDT
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 16:23:03 EDT
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 17:16:55 EDT
(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 03:13:39 EDT
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.