|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49382 can't access DateTime->date
Submitted: 2009-08-27 07:52 UTC Modified: 2017-03-24 15:38 UTC
Avg. Score:4.0 ± 1.0
Reproduced:73 of 74 (98.6%)
Same Version:38 (52.1%)
Same OS:20 (27.4%)
From: klawd at kamundo dot de Assigned: derick (profile)
Status: Not a bug Package: Date/time related
PHP Version: 7.1 OS: Debian GNU/Linux 5.0
Private report: No CVE-ID: None
 [2009-08-27 07:52 UTC] klawd at kamundo dot de
Can not access property date of DateTime.

Reproduce code:
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt->date;
gets me Notice: Undefined property: DateTime::$date

strangely though, this works:
$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt->date;
DateTime Object ( [date] => 1742-05-23 00:00:00 [timezone_type] => 3 [timezone] => UTC ) 1742-05-23 00:00:00


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-03-07 20:22 UTC]
-Package: Date/time related +Package: Feature/Change Request
 [2010-03-07 20:22 UTC]
->date being available is actually a side-effect of support for var_dump() here. I'll mark this as a feature request as it was not intended to work.
 [2010-08-04 22:36 UTC] weirdan at gmail dot com
if this was not intended to work this way, why won't you just fix it so that no 
properties are created as a result of print_r / Reflection::export() / foreach() / 
property_exist / array cast?
 [2010-11-18 12:29 UTC]
-Package: Feature/Change Request +Package: Date/time related
 [2012-12-29 17:56 UTC] info at metashock dot net
I think it is interesting that the property can be accessed using reflection. Using the following example I can access the property:

$dt = new DateTime();
$o = new ReflectionObject($dt);
$p = $o->getProperty('date');
$date = $p->getValue($dt)); // returns the value of DateTime::$date
 [2013-07-09 11:29 UTC] hanskrentel at yahoo dot de
I wonder how this qualifies as a bug as any object can have variable properties 
and accessing undefined ones give notices.

Just sounds like standard PHP behavior here.
 [2013-07-09 11:35 UTC] weirdan at gmail dot com
I'd say the bug is not that the property is not present before var_dump'ing 
object, but that the property is suddenly created. Unexpected side-effect.
 [2014-12-08 17:48 UTC] phpbug at sirdiego dot de
Okay, so I don't know if this is new or relevant in any case, but I found something similar to var_dump.

php > $object = new \DateTime();
php > echo $object->date . PHP_EOL;
PHP Notice:  Undefined property: DateTime::$date in php shell code on line 1
PHP Stack trace:
PHP   1. {main}() php shell code:0

php > get_object_vars($object);
php > echo $object->date . PHP_EOL;
2014-12-08 18:44:15

For me this also an unexpected side-effect and would say it is a bug.
 [2015-12-23 04:03 UTC] novell at att dot net
This may be a duplicate comment - my system hiccuped and I'm not sure the first one was actually sent.

print_r also causes the date element of DateTime object to be available the "wrong" way.
 [2016-07-06 10:42 UTC] valterms at gmail dot com
How I worked around the problem:

$dt=new DateTime('2016-07-06 00:00:00');
$tmpObj = (array)($dt); // Only for circumvention, without this line $dt->date return null.
$dtx  = $dt->date;
echo $dtx; // display: 2016-07-06 00:00:00
 [2017-01-11 17:14 UTC]
-PHP Version: 5.3.0 +PHP Version: 7.1
 [2017-01-11 17:14 UTC]
It looks as if the property can only be accessed after a var_Dump or print_r of the object.

The question is whether the intended behaviour is to have the properties protected or not.

This is still valid in supported versions as shows!
 [2017-03-24 06:18 UTC]
-Status: Assigned +Status: Not a bug
 [2017-03-24 06:18 UTC]
Not everything that is possible is intended. Here it is not intended to access the properties of the DateTime-Object directly. So instead of accessing $date->date the intended behaviour is to use $date->format() with a format you expect. Everything else can break at any time due to internal refactoring of the way DAteTime handles the dates internally. Therefore the only bug in this issue is someone using a hack that is not intended!

The fact that the property is accessible after a debugging-statement is related to exactly that: debugging.
 [2017-03-24 12:55 UTC] weirdan at gmail dot com
> Here it is not intended to access the properties of the DateTime-Object directly.

Totally, and the fact that people cannot access this property is *not* a bug.


> The fact that the property is accessible after a debugging-statement

is certainly a bug (and is the worst kind of bug: heisenbug[1]). var_dump() and friends is intended to be read only as far as the dumped variable contents is concerned. I suspect current Datetime behaviour is there to expose internal object state for debugging purposes, but instead of providing a projection it materialiazes the property, so to speak. 

Can't the same (useful) effect of exposing the internal state be achieved by implementing a __debugInfo[2] method on Datetime objects, without harmful side effect of property materialization?

 [2017-03-24 13:29 UTC]
-Status: Not a bug +Status: Re-Opened
 [2017-03-24 13:29 UTC]
Indeed, the fact that these properties are accessible after a var_dump() is a bug. I've been working on a solution in, but it didn't quite work out because Datetime unfortunately supports __set_state().
 [2017-03-24 15:38 UTC]
-Status: Re-Opened +Status: Not a bug
 [2017-03-24 15:38 UTC]
Sorry for being picky about this. As the cause for the Original Report is *not* a bug but a feature I'm going to close *this* issue.

As we all agree that having $date exposed after a degugging-statement I'm going to open a new issue regarding that.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 11:01:32 2024 UTC