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): php-common-5.1.6-20.el5_2.1 php-5.1.6-20.el5_2.1 php-cli-5.1.6-20.el5_2.1 tzdata-2008i-1.el5 How reproducible: Always 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: <?php echo date_default_timezone_get(); ?> Actual results: 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 Expected results: 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: http://us3.php.net/manual/en/function.date-default-timezone-get.php " 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.