Bug 469532 - Europe/London should be set as GMT/BST, not UTC
Summary: Europe/London should be set as GMT/BST, not UTC
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-11-02 00:26 UTC by Philip
Modified: 2009-07-14 14:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-14 14:17:53 UTC
Type: ---

Attachments (Terms of Use)
Test file that shows the problem (685 bytes, application/octet-stream)
2008-11-02 00:26 UTC, Philip
no flags Details
revised test script (578 bytes, text/plain)
2008-11-03 15:13 UTC, Nils Philippsen
no flags Details

Description Philip 2008-11-02 00:26:03 UTC
Created attachment 322198 [details]
Test file that shows the problem

Description of problem: When time-zone is set to Europe/London, it is set as UTC. It should be set as GMT. This prevents PHP from working correctly with daylight savings time.

Version-Release number of selected component (if applicable):

How reproducible:
It happens any time PHP refers to daylight savings time.

Steps to Reproduce:
1. Run attached test.php file.
2. Observe the output.
Actual results:
18-Oct-2008 11:34:46 UTC 0
01-Nov-2008 11:34:46 UTC 0

19-Oct-2008 12:34:46 BST 1
01-Nov-2008 11:34:46 GMT 0

18-Oct-2008 11:34:46 UTC 0
01-Nov-2008 11:34:46 UTC 0

Expected results:
19-Oct-2008 12:34:46 BST 1
01-Nov-2008 11:34:46 GMT 0

19-Oct-2008 12:34:46 BST 1
01-Nov-2008 11:34:46 GMT 0

18-Oct-2008 11:34:46 UTC 0
01-Nov-2008 11:34:46 UTC 0

Additional info:
Obviously the output depends on when you run the attached script. The code writes out the time now and then the time 2 weeks ago. At the moment, this spans the changeover from BST to GMT.

The first three lines use Fedora's system time setting (Europe/London).
The next three lines set the time to Europe/London in the PHP.
The last three lines set the time to UTC in the PHP.

As you can see the system setting is UTC and daylight savings doesn't show up with UTC. The PHP people tell me this is how it is meant to be so it's a Fedora bug not a PHP bug. See here: http://bugs.php.net/bug.php?id=46459

Comment 1 Nils Philippsen 2008-11-03 15:13:05 UTC
The timezone that system-config-date sets is Europe/London, not UTC. Look:

nils@gibraltar:~> system-config-date
[... set timetone to Europe/London ...]
nils@gibraltar:~> sha1sum /etc/localtime /usr/share/zoneinfo/Europe/London 
e203aaf15eecc56c069b59f482f8ae3655c249a9  /etc/localtime
e203aaf15eecc56c069b59f482f8ae3655c249a9  /usr/share/zoneinfo/Europe/London

I've changed your test script a bit, i.e. it uses the fixed dates of June 1st and December 1st, 2008 instead of working from the current date (makes it easier for reproducability). I'll attach the changed script to this bug, here's its output:

--- 8< ---
nils@gibraltar:~> php ~/tmp/bz469532_test.php 
Timezone:	UTC
DST:		01-Jun-2008 12:00:00 UTC 0
non DST:	01-Dec-2008 12:00:00 UTC 0

Timezone:	Europe/London
DST:		01-Jun-2008 12:00:00 BST 1
non DST:	01-Dec-2008 12:00:00 GMT 0

Timezone:	UTC
DST:		01-Jun-2008 12:00:00 UTC 0
non DST:	01-Dec-2008 12:00:00 UTC 0

--- >8 ---

As you can see, if /etc/localtime is the same as Europe/London and there are no calls to date_default_timezone_set(), the date_default_timezone_get() function identifies the timezone as UTC instead of Europe/London. I therefore suspect that the PHP date_default_timezone_get() function is faulty or possibly library code behind it.

Comment 2 Nils Philippsen 2008-11-03 15:13:57 UTC
Created attachment 322310 [details]
revised test script

Comment 3 Nils Philippsen 2008-11-03 15:17:56 UTC
NB: stracing the script reveals that (all?) zoneinfo files beneath /usr/share/zoneinfo get stat()ed, I guess to check which one is the same as /etc/localtime -- if my guess is correct, this check fails for whatever reason.

Comment 4 Nils Philippsen 2008-11-03 15:18:33 UTC
NB^2: I did my testing on current (pre-F10) Rawhide, with the same results as the reporter.

Comment 5 Joe Orton 2008-11-04 09:43:48 UTC
PHP is working as intended here, there's nothing Fedora-specific about this, so far as I can tell.  The PHP default timezone follows the logic in the docs:


and in the final case, it runs localtime() to get a timezone abbreviation, and that gives "GMT" currently if /etc/localtime Europe/London; and GMT is mapped to "UTC".

I guess the root issue here is that PHP seems to want to derive an actual timezone *name* for the default timezone.  There's no trivial way to do a reverse lookup based on /etc/localtime to get back to a name.  I guess you could build up a hash table of all the files in /usr/share/zoneinfo, and compare that against the hash of /etc/localtime.

Comment 6 Joe Orton 2008-11-04 10:03:56 UTC
I'll take this is as a feature request; I think it's reasonable to expect that PHP does the right thing here.

We already scan the zoneinfo database so building up hashes and comparing against hash(/etc/localtime) is not so unreasonable.  It's a shame that /etc/localtime is a copy rather than a symlink, that would make it much simpler!

Comment 7 Joe Orton 2008-11-04 10:52:12 UTC
Or, better yet, perhaps PHP could just use an artificial timezone name which corresponds to "the current system timezone as defined by /etc/localtime".

Comment 8 Joe Orton 2008-11-04 11:29:52 UTC
I'm building a patched version of php which introduces an artificial timezone name of


which is used as the fallback if date.timezone/$TZ/etc are not set; this will correspond to the system local timezone as defined by /etc/localtime.

Comment 9 Joe Orton 2008-11-04 12:46:02 UTC
Build in dist-f10-updates-candidate:

[jorton@zebedee ~]$ rpm -q php
[jorton@zebedee ~]$ php -f bug469532.php 
tz is System/Localtime
Timezone:	System/Localtime
DST:		01-Jun-2008 12:00:00 BST 1
non DST:	01-Dec-2008 12:00:00 GMT 0

Timezone:	Europe/London
DST:		01-Jun-2008 12:00:00 BST 1
non DST:	01-Dec-2008 12:00:00 GMT 0

Timezone:	UTC
DST:		01-Jun-2008 12:00:00 UTC 0
non DST:	01-Dec-2008 12:00:00 UTC 0

Comment 10 Nils Philippsen 2008-11-05 17:08:31 UTC
Not that I have much stake in here, but if PHP already looks at all the timezones available, it could also identify which one is the same as /etc/localtime without much additional cost (and resort to "System/Localtime" if it can't identify it). The reasoning why /etc/localtime is a copy instead of a symlink is that /usr may not be available on boot (and the symlink would dangle then).

Comment 11 Nigel Jones 2009-01-02 10:39:01 UTC
I've just tried the patch for that is the -6 RPM (in koji), meets/fixes my testcase in bug #478568, it actually makes the output look better.

Instead of EST (which can cause a lot of confusion) it causes 'echo date(DATE_RFC822);' to print "+1000", so a big Works For Me here!

Comment 12 Joe Orton 2009-02-04 16:43:48 UTC
An expletive-filled rant about the impact of this change:


Comment 13 Bug Zapper 2009-06-10 03:08:43 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 14 Bug Zapper 2009-07-14 14:17:53 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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