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. 3. Actual results: UTC 18-Oct-2008 11:34:46 UTC 0 01-Nov-2008 11:34:46 UTC 0 Europe/London 19-Oct-2008 12:34:46 BST 1 01-Nov-2008 11:34:46 GMT 0 UTC 18-Oct-2008 11:34:46 UTC 0 01-Nov-2008 11:34:46 UTC 0 Expected results: UTC 19-Oct-2008 12:34:46 BST 1 01-Nov-2008 11:34:46 GMT 0 Europe/London 19-Oct-2008 12:34:46 BST 1 01-Nov-2008 11:34:46 GMT 0 UTC 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
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.
Created attachment 322310 [details] revised test script
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.
NB^2: I did my testing on current (pre-F10) Rawhide, with the same results as the reporter.
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: http://uk3.php.net/manual/en/function.date-default-timezone-get.php 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.
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!
Or, better yet, perhaps PHP could just use an artificial timezone name which corresponds to "the current system timezone as defined by /etc/localtime".
I'm building a patched version of php which introduces an artificial timezone name of System/Localtime 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.
Build in dist-f10-updates-candidate: [jorton@zebedee ~]$ rpm -q php php-5.2.6-6.x86_64 [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
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).
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!
An expletive-filled rant about the impact of this change: http://trac.agavi.org/ticket/1008
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
This comment was flagged a spam, view the edit history to see the original text if required.