In OpenSuSE 12.1 i can reproduce this issue.
My workaround is to check the correct timezone.
On Tue, 15 Nov 2011 23:34:18 +0100, Geoff Shang <geoff@xxxxxxxxxxxxxxx>
wrote:
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.
--
best regards,
Patty
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
