Bug->Doc #60212 [Opn->Csd]: Unexpected behaviour while adding or subtracting relative time with strtotime

Edit report at https://bugs.php.net/bug.php?id=60212&edit=1 ID: 60212 Updated by: danielc@php.net Reported by: reetz at krumedia dot de Summary: Unexpected behaviour while adding or subtracting relative time with strtotime -Status: Open +Status: Closed -Type: Bug +Type: Documentation Problem Package: Date/time related Operating System: Linux version 2.6.32-5-amd64 PHP Version: 5.3.8 -Assigned To: +Assigned To: danielc Block user comment: N Private report: N New Comment: Mixing and matching time zones is your problem. Date mathematics should use add()/sub() in PHP >= 5.3 or modify() in PHP 5.2. I have updated the manual accordingly. The changes will show up the next time the manual is built. Previous Comments: ------------------------------------------------------------------------ [2011-11-21 17:10:10] danielc@php.net Automatic comment from SVN on behalf of danielc Revision: http://svn.php.net/viewvc/?view=revision&revision=319642 Log: Clarify time zone situation and specify that add/sub/modify are better for math (closes bug #60212). ------------------------------------------------------------------------ [2011-11-16 20:28:26] reetz at krumedia dot de For clarification of my problem I have made another demo code. Here, the difference of the timezone, it is clearly demonstrated. I have included your suggestion with the DateTime objects. It works perfectly. Unfortunately I still have a PHP 5.2 on my productive system and can not upgrade it. I am now using the version "-60" for these PHP environments. But still, since "strtotime" shows the same behaviour on PHP 5.3, I am left wondering if it does what it should do? If the answer to this is "yes", it may be good to consider some warnings in the manual. php -r " date_default_timezone_set('Europe/Berlin'); echo date_default_timezone_get().PHP_EOL; echo date('O').PHP_EOL; echo strtotime('2011-10-30 01:00 UTC').PHP_EOL; echo (-60+strtotime('2011-10-30 01:00 UTC')).PHP_EOL; echo strtotime('-1 minute',strtotime('2011-10-30 01:00 UTC')).PHP_EOL; echo PHP_EOL; date_default_timezone_set('UTC'); echo date_default_timezone_get().PHP_EOL; echo date('O').PHP_EOL; echo strtotime('2011-10-30 01:00 UTC').PHP_EOL; echo (-60+strtotime('2011-10-30 01:00 UTC')).PHP_EOL; echo strtotime('-1 minute',strtotime('2011-10-30 01:00 UTC')).PHP_EOL; echo PHP_EOL; date_default_timezone_set('Europe/Berlin'); echo date_default_timezone_get().PHP_EOL; echo date('O').PHP_EOL; \$d = new DateTime('2011-10-30 01:00 UTC'); echo \$d->getTimestamp().PHP_EOL; \$d->sub(DateInterval::createFromDateString('1 minute')); echo \$d->getTimestamp().PHP_EOL; " Europe/Berlin +0100 1319936400 1319936340 1319932740 UTC +0000 1319936400 1319936340 1319936340 Europe/Berlin +0100 1319936400 1319936340 Sincerely Yours Michael Reetz ------------------------------------------------------------------------ [2011-11-16 17:04:39] rasmus@php.net Of course, if you are not working in UTC then strtotime("-1 minute") is going to use the current timezone to figure out the timestamp of 1 minute ago. "-1 minute UTC" makes no sense because that is a relative time. It needs to know what to subtract 1 minute from in order to give you an absolute timestamp of 1 minute ago. A better approach is to use DateTime objects as per php.net/datetime and then you can use the date_sub() function to subtract intervals. ------------------------------------------------------------------------ [2011-11-16 16:57:58] rasmus@php.net php -a Interactive shell php > echo strtotime('-1 minute', strtotime('2011-10-30 01:00 UTC')); 1319936340 php > echo -60 + strtotime('2011-10-30 01:00 UTC'); 1319936340 Looks the same for me both in 5.3.8 and 5.4.0 ------------------------------------------------------------------------ [2011-11-03 18:16:11] reetz at krumedia dot de Please take the time and read my report properly . I am well aware of "DAYLIGHT SAVING TIME". I am even aware that not all countries have their DST on the same date, into the same direction or at all. For example Australian (except NT, WA and QLD) Standard Time: 3 April 2011 to 2 October 2011 Summer Time : 2 October 2011 to 1 April 2012 European Summer Time : 27 March 2011 to 30 October 2011 Standard Time: 30 October 2011 to 25 March 2012 Rusia : DST no longer in use Saudi Arabia : DST never used So, please do not use such a dismissive language. I was using UTC values. There is no room for DST interpretation in UTC. My whole application calculates in UTC. All time conversions are done with strtotime('.... UTC') and gmdate('Y-m-d H:i:s \U\T\C') because of DST. I was supplying an DST-free Time. I was already searching for a "strtotime('-1 minute UTC',..)", no such luck! Why is php -r "echo strtotime('-1 minute', strtotime('2011-10-30 01:00 UTC'));" not the same as php -r "echo -60 + strtotime('2011-10-30 01:00 UTC');" The first returns 1319932740 and the second returns 1319936340 while strtotime('2011-10-30 01:00 UTC') is 1319936400, but (1319936400 - 1319932740) equals 3660, that's one hour and 1 minute. Not one minute as requested! >>>Taken out of the manual: strtotime ".... will try to parse that format into a Unix timestamp (the number of seconds since January 1 1970 00:00:00 UTC)" Please enlighten me ! Why should "1319932740" be the result of php -r "echo strtotime('-1 minute', 1319936400);" even IF my operation systems time zone is "Europe/Berlin". The integer-value of a Unix-Timestamp has no Timezone. That is the whole point of Unix-timestamp. Why should -1 Minute of an integer value (of any date) be relevant to DST. The input is an Unix Timestamp, the output is an Unix Timestamp, the difference is 60 seconds. Where is the DST in this calculation? Really, tell me. The answer should be easy for someone with so much "more sense". Sincerely Yours Michael Reetz P.S. sorry for that last sentence, I am feeling better now. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60212 -- Edit this bug report at https://bugs.php.net/bug.php?id=60212&edit=1