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.


First, lets confirm that the system time is in fact set to Europe/London.

$ cmp --verbose /etc/localtime /usr/share/zoneinfo/Europe/London
$ echo $?

Now lets see what PHP thinks it is.

$ php -r 'echo date_default_timezone_get();'

What about if we set it in the environment?

$ export TZ=Europe/London
$ php -r 'echo date_default_timezone_get();'

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");'
$ 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");'
$ 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.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to