This is fixed in PHP 5.4 by completely dropping support for the TZ
environment variable. PHP will always use UTC unless you explicitly set
it to something. It won't matter which timezone the system is running
in. This is the only reliable way to always have consistent behaviour
across all environments.
-Rasmus
On 12/06/2011 04:46 PM, Patricia Dewald wrote:
>
> 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.
>>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
