php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #76588 var_export change variable state
Submitted: 2018-07-06 13:30 UTC Modified: 2022-06-04 15:43 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: sukei13 at gmail dot com Assigned: derick (profile)
Status: Closed Package: Date/time related
PHP Version: Irrelevant 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: sukei13 at gmail dot com
New email:
PHP Version: OS:

 

 [2018-07-06 13:30 UTC] sukei13 at gmail dot com 
Description:
------------
The result of a comparison (soft: ==) between two date intervals change when the variable has been exported (var_export) earlier. The var_export function affect the internal state of the DateInterval object in some way. The following test script show this weird behavior. Note that this test has been made on other objects too (such as DateTime or DateTimeImmutable) but DateInterval seems to be the only object involved in this issue.

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

$a = new DateInterval('P2Y4DT6H8M');
$b = new DateInterval('P2Y4DT6H8M');

var_dump($a == $b); // true

var_export($b, true);

var_dump($a == $b); // false

Expected result:
----------------
bool(true)
bool(true)

Actual result:
--------------
bool(true)
bool(false)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-07-06 13:37 UTC] sukei13 at gmail dot com 
Doing further tests, it appears that the print_r function has the same behavior as var_export.
 [2018-07-13 22:10 UTC] cmb@php.net
-Package: *General Issues +Package: Date/time related
 [2020-06-14 22:26 UTC] cmb@php.net
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2020-06-14 22:26 UTC] cmb@php.net 
Comparing DateInterval instances cannot be well defined (consider
e.g. P1M and P30D); as of PHP 7.4.0, comparisons raise a warning
and evaluate to FALSE.  Prior to that version, their behavior was,
let's say, undefined.

While that change is noted in the migration guide[1], it is not
yet documented in the manual proper (not sure, *where* this should
be documented).

[1] <https://www.php.net/manual/en/migration74.incompatible.php#migration74.incompatible.datetime>
 [2021-04-07 16:40 UTC] cmb@php.net 
See also bug #74054, which is a request to change that.
 [2022-06-04 15:43 UTC] derick@php.net
-Status: Verified +Status: Closed -Assigned To: +Assigned To: derick
 [2022-06-04 15:43 UTC] derick@php.net 
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php

This is already documented on the introduction page of the DateInterval class.

https://www.php.net/dateinterval :

Since there is no well defined way to compare date intervals, DateInterval instances are incomparable.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Apr 20 05:01:27 2024 UTC