Bug 478568 - PHP defaults to incorrect timezone when system uses Australia/Brisbane
PHP defaults to incorrect timezone when system uses Australia/Brisbane
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: php (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2008-12-31 23:38 EST by Nigel Jones
Modified: 2009-09-01 09:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-01 09:01:30 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 Nigel Jones 2008-12-31 23:38:01 EST
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):

How reproducible:

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:

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'
Comment 1 Nigel Jones 2008-12-31 23:45:16 EST
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?)
Comment 2 Joe Orton 2009-01-02 03:56:22 EST
See bug 469532 - this is fixed in Fedora 10.  I'm not sure we could back port that solution to RHEL, though.
Comment 3 Nigel Jones 2009-01-02 04:31:55 EST
(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.
Comment 4 Joe Orton 2009-09-01 09:01:30 EDT
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.

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