Edit report at https://bugs.php.net/bug.php?id=81458&edit=1
ID: 81458
Comment by: kylekatarnls at gmail dot com
Reported by: kylekatarnls at gmail dot com
Summary: Regression in PHP 8.1: Incorrect difference after
timezone change
Status: Assigned
Type: Bug
Package: Date/time related
PHP Version: 8.1Git-2021-09-18 (Git)
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
cmb@php.net > No, the difference between those 2 moments is 24 hours, not 20 hours.
No hours are added or subtracted when calling setTimezone, only the timezone change not the moment,
it's a meta data that should be used only to format the date, it has no impact on the
difference with an other moment.
Sorry but no, the current behavior is not correct. No way, 1 is correct (it's really 1 FULL DAY
diff), and 0 is wrong.
Previous Comments:
------------------------------------------------------------------------
[2021-10-21 15:42:59] antonino dot spampinato86 at gmail dot com
days
If the DateInterval object was created by DateTime::diff(), then this is the total number of days
between the start and end dates. Otherwise, days will be false.
Before PHP 5.4.20/5.5.4 instead of FALSE you will receive -99999 upon accessing the property.
It is a bug, however a date can be less than a day this can be handled by the user code side.
------------------------------------------------------------------------
[2021-10-21 15:13:07] antonino dot spampinato86 at gmail dot com
After explaining the difference between the new diff behavior from php 8.1 the algorithm has also
changed unfortunately SetTimeZone uses the server time and not the DateTime diff object does not
recognize +00: 00 but UTC for this reason forces UTC in the code.
$first = (new DateTime('2018-07-01 00:00:00.000000 America/Toronto'));
$first = (new DateTime('@' . $first->format('U')));
$first = (new DateTime($first->format('Y-m-d H:i:s'), new
DateTimeZone('UTC')));
// ->setTimezone(new DateTimeZone('UTC'));
$second = new DateTime('2018-07-02 00:00:00.000000 America/Toronto');
$result = $first->diff($second);
var_dump($first);
var_dump($second);
var_dump('UTC ' . ((new DateTime('@' .
$second->format('U')))->format('Y-m-d H:i:s')));
var_dump($result->days);
var_dump($result->d);
var_dump($result);
------------------------------------------------------------------------
[2021-10-21 13:44:32] antonino dot spampinato86 at gmail dot com
https://www.php.net/manual/en/datetime.examples-arithmetic.php
diff from php 8.1 compares the dates for the moment, while previously subtracting or adding hours.
The transition problem still exists, well the difference is one hour (backwards or forwards).
Between these two dates what is the difference php is less accurate than the human calculation?
2010-03-01 America/Sydney to 2010-07-29 America/Sydney From php 8.1 4 months and 28 days. Never 5
months (old incorrect aritmetic).
https://3v4l.org/5KhLZ
Relative ti bug #52480
it is understandable to restore the old behavior but updating the documentation with the first note
the calculation is wrong.
------------------------------------------------------------------------
[2021-10-21 13:23:19] cmb@php.net
Related To: Bug #81263
------------------------------------------------------------------------
[2021-10-21 10:53:24] cmb@php.net
See <https://3v4l.org/RiYdl>.
While there is obviously a behavioral change as of PHP 8.1.0, it
seems to me that the new behavior of ::$days is correct. In the
given test script there is a difference of 20 hours, and that is
less than a day. Unfortunately, the documentation is not
particularly clear whether this is to be expected, and why ::$d
has a different result.
Derick, can you please clarify?
------------------------------------------------------------------------
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=81458
--
Edit this bug report at https://bugs.php.net/bug.php?id=81458&edit=1