Edit report at https://bugs.php.net/bug.php?id=61955&edit=1
ID: 61955
Comment by: whistl0r+php at googlemail dot com
Reported by: php at arjanonline dot net
Summary: Adding DateInterval to DateTime adds 1 additional
hour
Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Linux / Mac
PHP Version: 5.3.12
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
This bug seems to be still present in PHP 5.3.19. My test script:
<?php
// The local system is set to Europe/Berlin timezone, so set it for PHP, too:
date_default_timezone_set( 'Europe/Berlin');
echo 'Current date: ' . date('c') . PHP_EOL;
// Now, we are switching to UTC...
date_default_timezone_set( 'UTC');
$timezone = new DateTimeZone( 'UTC' );
$datetime = new DateTime( null, $timezone );
$datetime->setTime( 00, 00, 00 );
$datetime->add( new DateInterval( 'P1D' ) );
// Output
echo 'mktime(): ' . ( mktime( 23, 59, 59 ) + 1 ) . PHP_EOL;
echo 'gmmktime(): ' . ( gmmktime( 23, 59, 59 ) + 1 ) . PHP_EOL;
echo 'datetime(): ' . $datetime->getTimestamp() . PHP_EOL;
echo 'time(): ' . time() . PHP_EOL;
echo 'microtime(): ' . microtime( true ) . PHP_EOL;
echo 'Used TZ: ' . date_default_timezone_get() . PHP_EOL;
?>
I run this test script at 2012-11-24T00:00:00+01:00. This is my output:
Current date: 2012-11-24T00:00:00+01:00
mktime(): 1353715200
gmmktime(): 1353715200
datetime(): 1353715200
time(): 1353711600
microtime(): 1353711600.7557
Used TZ: UTC
I am expecting that at least the DateTime value should be equal to time(),
because both functions should represent a UNIX timestamp (which is per
definition UTC).
But I am also not sure if the gmmktime() *and* mktime() should be equal... and
I don't understand the 3600 offset at all - remember, we set UTC timezone
before...
Previous Comments:
------------------------------------------------------------------------
[2012-09-11 19:13:10] chris dot baker dot gr at gmail dot com
To amend my earlier comment: my repro attempts show that if I create an
instance of DateTime by passing a string to the constructor, everything works
fine. If I use a timestamp in combination with DateTime::createFromFormat, I
see the bug affect the results
Use of a string
-------------------------
$start = new DateTime('09/13/2012 7:00pm');
$end = new DateTime('09/13/2012 8:00pm');
$interval = DateInterval::createFromDateString('30 minutes');
// expected, 1 hours, 0 minutes, get 1 hours, 0 minutes
$diff = $start->diff($end);
print 'Diff: '.$diff->h.' hours, '.$diff->i.' minutes'."\n";
$end->add($interval);
$diff = $start->diff($end);
// ecpected: 1 hours, 30 minutes, get 1 hours, 30 minutes
print "\n".'Diff after interval: '.$diff->h.' hours, '.$diff->i.' minutes';
Use of a timestamp
-------------------------
$start = DateTime::createFromFormat('U', 1347577200);
$end = DateTime::createFromFormat('U', 1347580800);
$interval = DateInterval::createFromDateString('30 minutes');
// expected, 1 hours, 0 minutes, get 1 hours, 0 minutes
$diff = $start->diff($end);
print 'Diff: '.$diff->h.' hours, '.$diff->i.' minutes'."\n";
$end->add($interval);
$diff = $start->diff($end);
// ecpected: 1 hours, 30 minutes, get 2 hours, 30 minutes
print "\n".'Diff after interval: '.$diff->h.' hours, '.$diff->i.' minutes';
http://3v4l.org/fivbW
The extra one hour makes less sense considering that my server timezone is -5
UTC -- not that it makes sense for DateInterval to be sensitive to timezone!
------------------------------------------------------------------------
[2012-09-11 14:58:51] chris dot baker dot gr at gmail dot com
Can reproduce this as well, just determined it to be the cause of new errors in
a scheduling web app after updating to 5.4.
------------------------------------------------------------------------
[2012-07-09 19:47:08] jgardynik at endlessrealities dot com
I'm getting the same thing. Any single date_modify() call is causing an extra
hour to be added. If I add 1 minute, it still adds an extra hour. The commit
that was bisected is very clearly adding an extra hour. If I use
Pacific/Honolulu or UTC in date_default_timezone_set() it works fine.
Apparently the fix was not specific enough in its implementation and it's
taking effect all the time.
This is causing every single one of my monthly comparison reports to break in a
rather large system because the time is getting thrown off.
I'm using PHP 5.4.4 on linux.
------------------------------------------------------------------------
[2012-05-19 15:03:40] graham at grahamc dot com
One minor clarification - This is occurring in every version above 5.3.8.
After running git bisect, I've narrowed it down to this particular commit:
https://github.com/php/php-src/commit/7411ae09f5565b3f0dfbbfeb71c8f848fd38d6ca
------------------------------------------------------------------------
[2012-05-11 15:51:21] zhanglijiu at gmail dot com
My result is object(DateTime)#2 (3) { ["date"]=> string(19) "1970-01-01
00:00:05"
["timezone_type"]=> int(1) ["timezone"]=> string(6) "+00:00" }
My system is MAC 10.6.8 php 5.3.1
------------------------------------------------------------------------
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=61955
--
Edit this bug report at https://bugs.php.net/bug.php?id=61955&edit=1
