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
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 !
Your email address:
MUST BE VALID
Solve the problem:
30 - 30 = ?
Subscribe to this entry?

 
 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2019 The PHP Group
All rights reserved.
Last updated: Fri Nov 15 04:01:34 2019 UTC