Hi,
A couple of weeks ago, I discovered what I'm pretty sure is a PHP bug.
In addition, I looked in the PHP changelog and I haven't seen any mention
of a fix for it.
I'm writing here because I was wondering if anyone else can confirm it and
what to do about it.
The bug is that if a server's timezone is set to Europe/London and you
don't set an explicit timezone in your script, if it's winter time in
the UK, PHP thinks the timezone is UTC instead of Europe/London.
Example:
First, lets confirm that the system time is in fact set to Europe/London.
$ cmp --verbose /etc/localtime /usr/share/zoneinfo/Europe/London
$ echo $?
0
Now lets see what PHP thinks it is.
$ php -r 'echo date_default_timezone_get();'
UTC
What about if we set it in the environment?
$ export TZ=Europe/London
$ php -r 'echo date_default_timezone_get();'
Europe/London
OK, so we appear to have an issue. But is this just semantics? Well no.
consider the following (with TZ once again unset):
$ php -r 'echo date ("r", strtotime ("1 July 2011 12:00 pm"'
Fri, 01 Jul 2011 12:00:00 +0000
But of course, Europe/London isn't on +0000 in July.
$ export TZ=Europe/London
$ php -r 'echo date ("r", strtotime ("1 July 2011 12:00 pm"));'
Fri, 01 Jul 2011 12:00:00 +0100
The problem comes in when we view times created in one and printed in
the other:
$ unset TZ
$ php -r 'echo strtotime ("1 July 2011 12:00 pm");'
1309521600
$ export TZ=Europe/London
$ php -r 'echo date ("r", 1309521600);'
Fri, 01 Jul 2011 13:00:00 +0100
And the opposite:
$ export TZ=Europe/London
$ php -r 'echo strtotime ("1 July 2011 12:00 pm");'
1309518000
$ unset TZ
$ php -r 'echo date ("r", 1309518000);'
Fri, 01 Jul 2011 11:00:00 +0000
This last one is what led me to discover this bug. We use automation
software to run our Internet radio station. The playout system is written
in C and the web front-end is written in PHP, with the data they work on
the only point of commonality between them. The station was set up during
the European summer. When the clocks changed, the playout system coped
but the PHP front-end was showing everything an hour out.
Now of course, I personally can force the front-end to use Europe/London
and it will work for me. And I guess ultimately it would make sense to
program the system to allow the user to specify a timezone rather than
relying on the server default. But right now it doesn't, and any solution
would need to take the playout system into account.
At any rate, none of this is the point. If you're using the system
default timezone, you expect it to (a) be correct and (b) be consistant.
Note that this bug may affect other timezones which are on UTC durin the
winter or summer, but I've not tested any other timezones as this would
mean changing the system timezone and I'm not real keen on doing that on
any of my systems.
This bug was found on a Debian Squeeze system running the following
version of PHP:
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011
08:24:40)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I realise this is 5.3.3 and that 5.3.8 is now out. It's possible that
this has been fixed but I could not find any traces of such a fix in the
changelogs.
I'd be interested to know if anyone else can confirm this bug and, if
confirmed, what I should do about it.
Thanks,
Geoff.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
