php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79452 DateTime::diff() generates months differently between time zones
Submitted: 2020-04-06 01:22 UTC Modified: 2020-04-06 11:51 UTC
From: corey dot taylor dot fl at gmail dot com Assigned:
Status: Open Package: Date/time related
PHP Version: 7.4.4 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
37 - 5 = ?
Subscribe to this entry?

 
 [2020-04-06 01:22 UTC] corey dot taylor dot fl at gmail dot com
Description:
------------
If you create DateTime instances in 'America/New_York' or 'UTC' time zone and compare them using DateTime::diff() the `months` value is different than using DateTime instances in 'Europe/Berlin' or 'Asia/Tokyo'.

date_default_timezone_set('America/New_York');

$from = new DateTime('2019-06-01');
$to = new DateTime('2019-10-01');

var_dump($from->diff($to)->m);

-- int(4)

date_default_timezone_set('Asia/Tokyo');

$from = new DateTime('2019-06-01');
$to = new DateTime('2019-10-01');

var_dump($from->diff($to)->m);

-- int(3)

The generated `days` value is the same for both.

If this isn't determined to be an implementation error, then can the exepcation be documented for DateTime::diff()? Right now, it's impossible to tell how the DateTime objects are compared between time zones.



Expected result:
----------------
The generated difference in months is the same for 2 dates is the same regardless of the time zone they are in.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-04-06 08:14 UTC] cmb@php.net
Before the actual diff is calculated, the DateTime objects are
converted to UTC; doing this in PHP shows the problem[1].

[1] <https://3v4l.org/gBtjX#v720>
 [2020-04-06 11:51 UTC] corey dot taylor dot fl at gmail dot com
I can see why php calculates the month value different for those UTC DateTime instances.

Is there no way to get a consistent calendar operation in different time zones? The only alternative here seems to be mimicking the same "date" in UTC for users in other time zones when calculating calendar changes.
 [2020-04-07 05:48 UTC] 1515888956 at qq dot com
calc error because timelib function apply time to gmttime.
so the different month is the gmt different month
l am alread motify this bug. but l don't not sure is right
https://github.com/derickr/timelib/pull/78
 [2020-05-06 14:38 UTC] antonino dot spampinato86 at gmail dot com
the error lies in the evaluation of +1 month from a date that begins at the end of May 31 since php calculates from the current month it takes initially 31 days on July 1 is the second month while it should be the third month. It should only calculate the time spent in months without days.
<?php
date_default_timezone_set('America/New_York');

$from = new DateTime('2019-06-01');
$to = new DateTime('2019-10-01');

var_dump($from->diff($to)->m);

date_default_timezone_set('Asia/Tokyo');

$from = new DateTime('2019-06-01');
$from->setTimezone(new DateTimeZone('UTC'));
// 2019-05-31 15:00:00
$to = new DateTime('2019-10-01');
$to->setTimezone(new DateTimeZone('UTC'));
// 2019-09-30 15:00:00
// 4 month for php 2019-10-01 15:00:00
var_dump(($from->diff($to)->m), $from, $to);
 [2020-05-06 14:53 UTC] antonino dot spampinato86 at gmail dot com
correction July 1st is the first month while it should be the second month.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Thu Nov 26 15:01:23 2020 UTC