Hi!
I've been looking into various tests and discovered something strange in
date_diff. Example code:
<?php
$start = new DateTime('2010-10-04 02:18:48 EDT');
$end = new DateTime('2010-11-06 18:38:28 EDT');
$int = $start->diff($end);
var_dump($start);
As a result of this I'm getting this:
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-10-04 06:18:48"
["timezone_type"]=>
int(2)
["timezone"]=>
string(3) "EDT"
}
As you can see, the date in $start changed, even though it shouldn't
happen. Looks like it's because of timelib_diff() which has this:
timelib_apply_localtime(one, 0);
timelib_apply_localtime(two, 0);
which converts times in diff arguments to localtime. It then does:
timelib_apply_localtime(one, 1);
timelib_apply_localtime(two, 1);
which is supposed to convert them back, but in fact it does not, since
first conversion seems to have killed TZ information. I'd propose to fix
it by making time_diff operate on copies of one and two instead of real
structures, but maybe somebody has a better idea?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I've been looking into various tests and discovered something strange in
date_diff. Example code:<?php
$start = new DateTime('2010-10-04 02:18:48 EDT');
$end = new DateTime('2010-11-06 18:38:28 EDT');
$int = $start->diff($end);
var_dump($start);As a result of this I'm getting this:
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-10-04 06:18:48"
["timezone_type"]=>
int(2)
["timezone"]=>
string(3) "EDT"
}As you can see, the date in $start changed, even though it shouldn't happen.
Looks like it's because of timelib_diff() which has this:timelib_apply_localtime(one, 0);
timelib_apply_localtime(two, 0);which converts times in diff arguments to localtime. It then does:
timelib_apply_localtime(one, 1);
timelib_apply_localtime(two, 1);which is supposed to convert them back, but in fact it does not, since first
conversion seems to have killed TZ information. I'd propose to fix it by
making time_diff operate on copies of one and two instead of real
structures, but maybe somebody has a better idea?
Just ran Stas' script against a lot of 5.3's.
V5.3.0alpha2 : string(19) "2010-10-04 06:18:48"
V5.3.0alpha3 : string(19) "2010-10-04 06:18:48"
V5.3.0beta1 : string(19) "2010-10-04 06:18:48"
V5.3.0RC2 : string(19) "2010-10-04 06:18:48"
V5.3.0RC3 : string(19) "2010-10-04 06:18:48"
V5.3.0RC4 : string(19) "2010-10-04 06:18:48"
V5.3.0 : string(19) "2010-10-04 06:18:48"
V5.3.1RC1 : string(19) "2010-10-04 06:18:48"
V5.3.1RC2 : string(19) "2010-10-04 06:18:48"
V5.3.1RC3 : string(19) "2010-10-04 06:18:48"
V5.3.1RC4 : string(19) "2010-10-04 06:18:48"
V5.3.1 : string(19) "2010-10-04 06:18:48"
V5.3.2RC1 : string(19) "2010-10-04 06:18:48"
V5.3.2RC2 : string(19) "2010-10-04 06:18:48"
V5.3.2RC3 : string(19) "2010-10-04 06:18:48"
V5.3.2 : string(19) "2010-10-04 06:18:48"
V5.3.3RC1 : string(19) "2010-10-04 06:18:48"
V5.3.3RC2 : string(19) "2010-10-04 06:18:48"
V5.3.3RC3 : string(19) "2010-10-04 06:18:48"
V5.3.3 : string(19) "2010-10-04 06:18:48"
V5.3.4RC1 : string(19) "2010-10-04 06:18:48"
V5.3.4RC2 : string(19) "2010-10-04 06:18:48"
V5.3.4 : string(19) "2010-10-04 06:18:48"
V5.3.5 : string(19) "2010-10-04 06:18:48"
V5.3.6RC1 : string(19) "2010-10-04 06:18:48"
V5.3.6RC2 : string(19) "2010-10-04 06:18:48"
V5.3.6RC3 : string(19) "2010-10-04 06:18:48"
V5.3.6 : string(19) "2010-10-04 06:18:48"
Even though the behaviour is wrong, it is consistent.
There are no user notes commenting on this issue in the documentation.
Can't check the bug base at the moment due to it being down.
If either of the dates use a TLA timezone (EDT, PST, GMT), rather than
the long name (Europe/London, Indian/Kerguelen,
America/Kentucky/Louisville), then that date is altered.
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
As you can see, the date in $start changed, even though it shouldn't happen.
Looks like it's because of timelib_diff() which has this:timelib_apply_localtime(one, 0);
timelib_apply_localtime(two, 0);which converts times in diff arguments to localtime. It then does:
timelib_apply_localtime(one, 1);
timelib_apply_localtime(two, 1);which is supposed to convert them back, but in fact it does not, since first
conversion seems to have killed TZ information. I'd propose to fix it by
making time_diff operate on copies of one and two instead of real
structures, but maybe somebody has a better idea?
Well, we need to check on why the TZ information got killed actually. As
that's not supposed to happen. I see why this happens in the library,
let me think of a way on how to fix this in a clean way.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi!
If either of the dates use a TLA timezone (EDT, PST, GMT), rather than
the long name (Europe/London, Indian/Kerguelen,
America/Kentucky/Louisville), then that date is altered.
Yes, this seems to be because TLA ones rely on ->z and ->dst which get
reset in timelib_unixtime2gmt() while other one relies on tzinfo which
is kept intact.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
If either of the dates use a TLA timezone (EDT, PST, GMT), rather
than the long name (Europe/London, Indian/Kerguelen,
America/Kentucky/Louisville), then that date is altered.Yes, this seems to be because TLA ones rely on ->z and ->dst which get
reset in timelib_unixtime2gmt() while other one relies on tzinfo which
is kept intact.
Yup. I'm fixing it right now.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
If either of the dates use a TLA timezone (EDT, PST, GMT), rather
than the long name (Europe/London, Indian/Kerguelen,
America/Kentucky/Louisville), then that date is altered.Yes, this seems to be because TLA ones rely on ->z and ->dst which get
reset in timelib_unixtime2gmt() while other one relies on tzinfo which
is kept intact.Yup. I'm fixing it right now.
Done... I had to do it by making a backup for now. It should be looked
at again though, and I've added that to my (long) todo list.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
If either of the dates use a TLA timezone (EDT, PST, GMT), rather
than the long name (Europe/London, Indian/Kerguelen,
America/Kentucky/Louisville), then that date is altered.Yes, this seems to be because TLA ones rely on ->z and ->dst which get
reset in timelib_unixtime2gmt() while other one relies on tzinfo which
is kept intact.Yup. I'm fixing it right now.
Done... I had to do it by making a backup for now. It should be looked
at again though, and I've added that to my (long) todo list.
Does it mean that all the tests Daniel added should work now?
http://news.php.net/php.cvs/65174
-Hannes
Hi!
Does it mean that all the tests Daniel added should work now?
http://news.php.net/php.cvs/65174
Unfortunately, not yet. There seems to be another bug there, diff works
fine now but add gives wrong result.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Does it mean that all the tests Daniel added should work now?
http://news.php.net/php.cvs/65174
Looks like ts->date conversion is broken on TLA timezones. Try:
<?php
$t = new DateTime('2010-11-06 18:38:28 EDT'); // prev, zt2
$ts = $t->format('U');
var_dump($ts);
$t->setTimestamp($ts);
var_dump($t);
That produces:
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-11-06 17:38:28"
["timezone_type"]=>
int(2)
["timezone"]=>
string(3) "EDT"
}
Which obviously is not what it should be. Looks like
timelib_unixtime2gmt() or timelib_update_from_sse() has some bug that
breaks it...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Does it mean that all the tests Daniel added should work now?
http://news.php.net/php.cvs/65174Looks like ts->date conversion is broken on TLA timezones. Try:
<?php
$t = new DateTime('2010-11-06 18:38:28 EDT'); // prev, zt2
$ts = $t->format('U');
var_dump($ts);
$t->setTimestamp($ts);
var_dump($t);That produces:
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-11-06 17:38:28"
["timezone_type"]=>
int(2)
["timezone"]=>
string(3) "EDT"
}Which obviously is not what it should be. Looks like timelib_unixtime2gmt() or
timelib_update_from_sse() has some bug that breaks it...
Yes, I know. It's probably because of the "dst" flag. I did see that
yesterday, but didn't have the time to fix it yet, or look at it.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi Hannes:
Does it mean that all the tests Daniel added should work now?
http://news.php.net/php.cvs/65174
Alas, no. There are other bugs in the bed.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi Stas:
$start = new DateTime('2010-10-04 02:18:48 EDT');
$end = new DateTime('2010-11-06 18:38:28 EDT');
$int = $start->diff($end);
... snip ...
As you can see, the date in $start changed, even though it shouldn't
happen.
Funny you should mention that now. I ran into the same exact issue as
I was reworking the DateTime unit tests yesterday. I came up with a
.phpt for it, and another one for a similar problem with DateTime::add(),
though I was waiting to commit them until bugs.php.net was back up so
I could get bug numbers for them.
I just updated my checkout and the diff() problem is fixed, but the
add() one still exists. bug.add.zone2.phpt has now been committed. In
brief, calling add() on DateTime objects with zone type2 pushes back the
time by an hour. For example:
<?php
$interval = new DateInterval('PT2H1M');
$date2 = new DateTime('2010-10-04 02:18:48 EDT');
echo $interval->format('Add %h hours %i minutes') . "\n";
$date2->add($interval);
echo 'Zone Type 2: ' . $date2->format('Y-m-d H:i:s T') . "\n";
?>
Output:
Zone Type 2: 2010-10-04 03:19:48 EDT
Expected:
Zone Type 2: 2010-10-04 04:19:48 EDT
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409