Red Hat Bugzilla – Bug 478568
PHP defaults to incorrect timezone when system uses Australia/Brisbane
Last modified: 2009-09-01 09:01:30 EDT
Description of problem:
PHP assumes an incorrect timezone when /etc/localtime has the contents of /usr/share/zoneinfo/posix/Australia/Queensland
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use system-config-date to change Timezone to Australia/Brisbane
2. Ensure that 'diff /etc/localtime /usr/share/zoneinfo/posix/Australia/Brisbane' returns nothing
3. Run a php script with the following contents:
Output will be: Australia/ACT
echo date(DATE_RFC822); will also produce a time that is 1 hour later than 'date' in a terminal/console
Australia/Brisbane OR Australia/Queensland
echo date(DATE_RFC822); to match system 'date'
I'd also like to point out the function from the PHP Manual:
In order of preference, this function returns the default timezone by:
* Reading the timezone set using the date_default_timezone_set() function (if any)
* Reading the TZ environment variable (if non empty)
* Reading the value of the date.timezone ini option (if set)
* Querying the host operating system (if supported and allowed by the OS)
If none of the above succeed, date_default_timezone_get will return a default timezone of UTC.
It is obviously reaching the 4th point, but it is not getting the right timezone (is that method flawed?)
See bug 469532 - this is fixed in Fedora 10. I'm not sure we could back port that solution to RHEL, though.
(In reply to comment #2)
> See bug 469532 - this is fixed in Fedora 10. I'm not sure we could back port
> that solution to RHEL, though.
Thanks for that note, I had not tested by reproducer under Fedora 10.
I've tried 5.2.6-6 (which appears to have the fix you've mentioned) this does solve the problem.
It would be very nice if the patch could be ported back.
The fix for this used in Fedora was reverted due to breaking at least one PHP webapp. So, this bug is not really fixable, without breaking by-design behaviour of PHP:
1) It is not possible to reliably map from /etc/localtime to a canonical timezone name.
2) PHP, and/or applications based on PHP, needs to be able to determine a timezone name.
So, the "correct" approach is to configure the timezone explicitly in /etc/php.ini. Regrettably, closing this bug.