Bug 478568

Summary:	PHP defaults to incorrect timezone when system uses Australia/Brisbane
Product:	Red Hat Enterprise Linux 5	Reporter:	Nigel Jones <dev>
Component:	php	Assignee:	Joe Orton <jorton>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.2
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-01 13:01:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nigel Jones 2009-01-01 04:38:01 UTC

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'

Comment 1 Nigel Jones 2009-01-01 04:45:16 UTC

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?)

Comment 2 Joe Orton 2009-01-02 08:56:22 UTC

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 09:31:55 UTC

(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 13:01:30 UTC

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.