php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75232 print_r of DateTime creating side-effect
Submitted: 2017-09-20 08:38 UTC Modified: 2019-04-18 13:52 UTC
Votes:11
Avg. Score:4.5 ± 0.8
Reproduced:8 of 8 (100.0%)
Same Version:8 (100.0%)
Same OS:7 (87.5%)
From: ben at redsnapper dot net Assigned: nikic (profile)
Status: Closed Package: Date/time related
PHP Version: 7.1.9 OS: any
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ben at redsnapper dot net
New email:
PHP Version: OS:

 

 [2017-09-20 08:38 UTC] ben at redsnapper dot net
Description:
------------
Using print_r on a DateTime object creates a side-effect: the property 'date' is now set and publicly available.



Test script:
---------------
//Expected Behaviour
php > $d1 = DateTime::createFromFormat("Ymd\THis\Z", '20170920T091600Z');
php > echo $d1->date;
Notice: Undefined property: DateTime::$date 

//Unexpected Behaviour / side effect.
php > $d2 = DateTime::createFromFormat("Ymd\THis\Z", '20170920T091600Z');
php > print_r($d2->date);
DateTime Object
(
    [date] => 2017-09-20 09:16:00.000000
    [timezone_type] => 3
    [timezone] => UTC
)

php > echo $d2->date;
2017-09-20 09:16:00.000000

Expected result:
----------------
There should be no change (side-effect) made to an object when using print_r()


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-09-20 09:05 UTC] gooh@php.net
For the sake of completeness, this also happens when var_dump'ing or ReflectionObject::export'ing:

php > $dt = new DateTime;
php > var_dump($dt);
object(DateTime)#3 (3) {
  ["date"]=>
  string(26) "2017-09-20 10:57:54.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Berlin"
}
php > echo $dt->date;
2017-09-20 10:57:54.000000

php > $dt = new DateTime;
php > ReflectionObject::export($dt);
Object of class [ <internal:date> class DateTime implements DateTimeInterface ] {
  // some lines omitted …

  - Dynamic properties [3] {
    Property [ <dynamic> public $date ]
    Property [ <dynamic> public $timezone_type ]
    Property [ <dynamic> public $timezone ]
  }

  // some lines omitted …
}
php > echo $dt->date;
2017-09-20 10:57:57.000000

So it adds three public properties.
 [2017-09-22 11:41 UTC] daverandom@php.net
-Status: Open +Status: Duplicate
 [2017-09-22 17:23 UTC] jhdxr@php.net
-Status: Duplicate +Status: Re-Opened
 [2017-09-22 17:23 UTC] jhdxr@php.net
@daverandom, bug #49382 was marked as "not a bug" because you believe that's a feature request rather than a bug. I don't think it's a good reason to close issue, but that't fine.

but this issue focus on the different behaviors of `$d->date` before and after `print_r`. There is no doubt that this inconsistency is a bug.
 [2018-07-06 14:41 UTC] cmb@php.net
Still unresolved: <https://3v4l.org/fN6HB>.
 [2018-09-29 12:36 UTC] nikic@php.net
-Summary: print_r creating side-effect. +Summary: print_r of DateTime creating side-effect
 [2019-04-18 13:52 UTC] nikic@php.net
-Status: Re-Opened +Status: Closed -Assigned To: +Assigned To: nikic
 [2019-04-18 13:52 UTC] nikic@php.net
This is fixed in 7.4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC