php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #81458 Regression in PHP 8.1: Incorrect difference after timezone change
Submitted: 2021-09-18 19:56 UTC Modified: -
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: kylekatarnls at gmail dot com Assigned:
Status: Open Package: Date/time related
PHP Version: 8.1Git-2021-09-18 (Git) OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: kylekatarnls at gmail dot com
New email:
PHP Version: OS:

 

 [2021-09-18 19:56 UTC] kylekatarnls at gmail dot com
Description:
------------
In PHP 8.0 diff()->days returned the total number of days between dates even if one of them were in UTC and not the other

In PHP 8.1 (since beta3 I think) ->d is still OK but ->days is now 0

Test script:
---------------
<?php

$first = (new DateTime('2018-07-01 00:00:00.000000 America/Toronto'))
    ->setTimezone(new DateTimeZone('UTC'));
$second = new DateTime('2018-07-02 00:00:00.000000 America/Toronto');

var_dump($first->diff($second)->days);
var_dump($first->diff($second)->d);


Expected result:
----------------
int(1)
int(1)

Actual result:
--------------
int(0)
int(1)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-09-19 14:39 UTC] antonino dot spampinato86 at gmail dot com
Since php 8.1 diff uses the moment instead of the timestamp, D indicates the days not covered by the month while days the days. then day one with zero time and with positive offset in timestamp (UTC) becomes the last of the previous month. For maximum compatibility check between dates that have the same timezone otherwise apply your diff method.
Related bug #52480
 [2021-09-19 14:43 UTC] antonino dot spampinato86 at gmail dot com
Sorry correct:
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.

d Number of days.
 [2021-09-19 14:55 UTC] kylekatarnls at gmail dot com
So we should get `false`, not `0`, we still have a bug then.

Moreover, we still have an integer number of days for the diff(), the timezone difference should have no impact there, as in real life you can have UTC vs. User timezone in similar comparisons, and then you will get different output depending on user timezone, and it will change from PHP 8.0 to 8.1, that's very dangerous.

For the library I maintain, then I have no choice but to convert date timezone for each date only for PHP 8.1 (as behavior is safe < 8.1), that will make the library (nesbot/carbon) slower in PHP 8.1, that's a bit sad I think.

And this is a breaking change, that should be carefully documented if you don't fix it.
 [2021-09-19 15:15 UTC] antonino dot spampinato86 at gmail dot com
Carbon or php <8.1 does not use the right code, a date must be calculated from its own moment. This speech is true only if between the same, otherwise offset first normalizes the date and then you convert to UTC or look at how many DST or ST between two dates with different offset and currently the php code does not provide this. It's arithmetic. Perhaps it would make sense to change into fatal error if calculating two dates with different time zones.

Human 2018-07-01 04:00:00 UTC to 2018-07-02 00:00:00 America/Toronto bug moment is 20 hours for diff, if converter to 2018-07-02 04:00:00 is 24 hours (maybe one day if without transitions DST or ST).
 [2021-09-19 19:33 UTC] kylekatarnls at gmail dot com
Again, I may understand the point about `1` being not the correct result, and that `false` would be the correct one.

But why `0`? It's non sense.

I know it's very tempting when facing a regression to blame users expectations or previous versions to be wrong. That looks to me like a confirmation bias.

Please triple-check this `int(0)` value in an objective way. How can it be correct?

If you "can't" calculate, then return `false` please, so we can detect it when checking an interval.

Thanks.
 [2021-09-19 22:20 UTC] antonino dot spampinato86 at gmail dot com
sorry for my english, if you use DateTime :: diff the value is a number sequence. From php 8 it incorrectly calculates the moment, i.e. the date string is the first parameter of DateTime between two dates, the result is 20 instead of 24 hours (one day). It is a bug but also php <8 which converts the date string to UTC, ie it loses or adds hours that expand per day. php <8 previously 2018-07-01 20:00:00 America / Toronto in diff was converted to 2018-07-02 00:00:00 UTC instead of using moment. Wait to hear from maintainer @dereck. i am a simple user i don't work for php :)

<?php

$first = (new DateTime('2018-07-01 00:00:00.000000 America/Toronto'))
    ->setTimezone(new DateTimeZone('UTC')); // 2018-07-01 04:00:00 UTC
$second = new DateTime('2018-07-02 00:00:00.000000 America/Toronto');

var_dump($first->diff($second)->days); //2018-07-01 04:00:00 UTC - 2018-07-02 00:00 Anerica/Toronto = 20 hours
var_dump($first->diff($second)->d);
var_dump($first->diff($second)->h);
 [2021-10-11 07:57 UTC] alec at alec dot pl
This is a bug and a regression. I hope it gets more attention before the final release.

From a user perspective it is obvious that the compared DateTime objects needs to be "converted internally" to the same timezone to do the calculations.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Oct 16 09:03:33 2021 UTC