Re: [PHP] Re: Think I found a PHP bug
Rasmus Lerdorf wrote: 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. Just taking that a step further ... The second that you need to actually take a users time zone into consideration, then the best way of working is to RUN the sever set to UTC. And store any time information in UTC. Then you can display times TO USERS either as UTC, or as their own local time or the local time of the location an event is happening at. You just need to remember that timezone information provided by the browser is only todays time offset, so any area with daylight saving will be wrong for half of the year, so that is the point you need to store a user or loction timezone reference. Many systems still only store 'offset' which is simply wrong :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Think I found a PHP bug
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 ge...@quitelikely.com 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 + But of course, Europe/London isn't on + 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 + 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
[PHP] Re: Think I found a PHP bug
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 ge...@quitelikely.com 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 + But of course, Europe/London isn't on + 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 + 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
