Edit report at https://bugs.php.net/bug.php?id=60212&edit=1
ID: 60212
User updated by: reetz at krumedia dot de
Reported by: reetz at krumedia dot de
Summary: Unexpected behaviour while adding or subtracting
relative time with strtotime
Status: Open
Type: Bug
Package: Date/time related
Operating System: Linux version 2.6.32-5-amd64
PHP Version: 5.3.8
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2011-11-03 16:53:51] anon at anon dot anon
No matter how many times I see these reports, it still absolutely boggles my
mind that so many PROGRAMMERS -- people you'd really think were capable of more
sense, can't spot DAYLIGHT SAVING TIME even when it's staring them right in the
face.
------------------------------------------------------------------------
[2011-11-03 15:07:17] reetz at krumedia dot de
Description:
------------
This problem only exists while using a time zone other than UTC, in my case
"Europe/Berlin".
I have to do relative time calculations and got an unexpected behaviour. I was
"missing" one hour of data and some data was misplaced. First I assumed, I had
forgotten an "UTC" or was using an "date" instead of "gmdate". Yet it was none
of the former. As it turns out, strtotime is doing something extremely
unexpected or even wrong.
The output consists of five columns, each contains timestamps formatted with "d
H:i \U\T\C"
- sUnexpectedTimePrevious // minus one minute by strtotime
- sTimePrevious // minus one minute as it should be
- sTimeNow //
- sTimeNext // plus one minute as it should be
- sUnexpectedTimeNext // plus one minute by strtotime
Lines with errors are marked with an exclamation marks. One line is of
particular interest:
! 29 23:59 UTC | 30 00:59 UTC | 30 01:00 UTC | 30 01:01 UTC | 30 01:01 UTC
Instead of one hour into the future it's now suddenly two one into the past.
For the record, yes I had done a search before submitting this report. I found
#54799 and #53370, yet I feel that the example I submitted might help analysing
the problem.
I am well aware that I could solve my problem by simply switching the default
time zone to "UTC". But this is only solving a symptom, not the real problem.
sincerely yours
Michael Reetz
Test script:
---------------
//date_default_timezone_set('UTC'); // no problem
date_default_timezone_set('Europe/Berlin'); // big problem
$iCurrent = strtotime('2011-10-29 23:55:00 UTC');
$iEnd = strtotime('2011-10-30 01:05:00 UTC');
while ($iCurrent <= $iEnd){
$sTimeNow = gmdate('d H:i \U\T\C',
$iCurrent );
$sTimePrevious = gmdate('d H:i \U\T\C', -60 +
$iCurrent );
$sTimeNext = gmdate('d H:i \U\T\C', 60 +
$iCurrent );
$sUnexpectedTimePrevious = gmdate('d H:i \U\T\C', strtotime('- 1
minute',$iCurrent));
$sUnexpectedTimeNext = gmdate('d H:i \U\T\C', strtotime('+ 1
minute',$iCurrent));
echo ($sUnexpectedTimePrevious != $sTimePrevious) ? '!':' ';
echo " $sUnexpectedTimePrevious | $sTimePrevious | $sTimeNow |
$sTimeNext | $sUnexpectedTimeNext ";
echo ($sUnexpectedTimeNext != $sTimeNext) ? '!':' ';
echo "\n";
$iCurrent += 60;
}
Expected result:
----------------
// created with : date_default_timezone_set('UTC');
29 23:54 UTC | 29 23:54 UTC | 29 23:55 UTC | 29 23:56 UTC | 29 23:56 UTC
29 23:55 UTC | 29 23:55 UTC | 29 23:56 UTC | 29 23:57 UTC | 29 23:57 UTC
29 23:56 UTC | 29 23:56 UTC | 29 23:57 UTC | 29 23:58 UTC | 29 23:58 UTC
29 23:57 UTC | 29 23:57 UTC | 29 23:58 UTC | 29 23:59 UTC | 29 23:59 UTC
29 23:58 UTC | 29 23:58 UTC | 29 23:59 UTC | 30 00:00 UTC | 30 00:00 UTC
29 23:59 UTC | 29 23:59 UTC | 30 00:00 UTC | 30 00:01 UTC | 30 00:01 UTC
30 00:00 UTC | 30 00:00 UTC | 30 00:01 UTC | 30 00:02 UTC | 30 00:02 UTC
30 00:01 UTC | 30 00:01 UTC | 30 00:02 UTC | 30 00:03 UTC | 30 00:03 UTC
[.. skipped several lines ..]
30 00:57 UTC | 30 00:57 UTC | 30 00:58 UTC | 30 00:59 UTC | 30 00:59 UTC
30 00:58 UTC | 30 00:58 UTC | 30 00:59 UTC | 30 01:00 UTC | 30 01:00 UTC
30 00:59 UTC | 30 00:59 UTC | 30 01:00 UTC | 30 01:01 UTC | 30 01:01 UTC
30 01:00 UTC | 30 01:00 UTC | 30 01:01 UTC | 30 01:02 UTC | 30 01:02 UTC
30 01:01 UTC | 30 01:01 UTC | 30 01:02 UTC | 30 01:03 UTC | 30 01:03 UTC
30 01:02 UTC | 30 01:02 UTC | 30 01:03 UTC | 30 01:04 UTC | 30 01:04 UTC
30 01:03 UTC | 30 01:03 UTC | 30 01:04 UTC | 30 01:05 UTC | 30 01:05 UTC
30 01:04 UTC | 30 01:04 UTC | 30 01:05 UTC | 30 01:06 UTC | 30 01:06 UTC
Actual result:
--------------
// created with : date_default_timezone_set('Europe/Berlin');
29 23:54 UTC | 29 23:54 UTC | 29 23:55 UTC | 29 23:56 UTC | 29 23:56 UTC
29 23:55 UTC | 29 23:55 UTC | 29 23:56 UTC | 29 23:57 UTC | 29 23:57 UTC
29 23:56 UTC | 29 23:56 UTC | 29 23:57 UTC | 29 23:58 UTC | 29 23:58 UTC
29 23:57 UTC | 29 23:57 UTC | 29 23:58 UTC | 29 23:59 UTC | 29 23:59 UTC
29 23:58 UTC | 29 23:58 UTC | 29 23:59 UTC | 30 00:00 UTC | 30 01:00 UTC !
29 23:59 UTC | 29 23:59 UTC | 30 00:00 UTC | 30 00:01 UTC | 30 01:01 UTC !
! 30 01:00 UTC | 30 00:00 UTC | 30 00:01 UTC | 30 00:02 UTC | 30 01:02 UTC !
! 30 01:01 UTC | 30 00:01 UTC | 30 00:02 UTC | 30 00:03 UTC | 30 01:03 UTC !
[.. skipped several lines ..]
! 30 01:57 UTC | 30 00:57 UTC | 30 00:58 UTC | 30 00:59 UTC | 30 01:59 UTC !
! 30 01:58 UTC | 30 00:58 UTC | 30 00:59 UTC | 30 01:00 UTC | 30 02:00 UTC !
! 29 23:59 UTC | 30 00:59 UTC | 30 01:00 UTC | 30 01:01 UTC | 30 01:01 UTC
30 01:00 UTC | 30 01:00 UTC | 30 01:01 UTC | 30 01:02 UTC | 30 01:02 UTC
30 01:01 UTC | 30 01:01 UTC | 30 01:02 UTC | 30 01:03 UTC | 30 01:03 UTC
30 01:02 UTC | 30 01:02 UTC | 30 01:03 UTC | 30 01:04 UTC | 30 01:04 UTC
30 01:03 UTC | 30 01:03 UTC | 30 01:04 UTC | 30 01:05 UTC | 30 01:05 UTC
30 01:04 UTC | 30 01:04 UTC | 30 01:05 UTC | 30 01:06 UTC | 30 01:06 UTC
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=60212&edit=1
