Bug 469532
Summary: | Europe/London should be set as GMT/BST, not UTC | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Philip <redhat> | ||||||
Component: | php | Assignee: | Joe Orton <jorton> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 9 | CC: | dev, fedora, jorton, nphilipp, rpm | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-07-14 14:17:53 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: | |||||||||
Attachments: |
|
Description
Philip
2008-11-02 00:26:03 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. 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. |