->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.

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?

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

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.

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.

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.

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.

http://stackoverflow.com/questions/34427627/very-interesting-behavior-of-a-datetime-object-and-access-to-its-elements-bi

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
...

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 https://3v4l.org/bEv47 shows!

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.

> 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.

However

> 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?

[1] https://en.wikipedia.org/wiki/Heisenbug
[2] http://php.net/manual/en/language.oop5.magic.php#object.debuginfo

Indeed, the fact that these properties are accessible after a var_dump() is a bug. I've been working on a solution in https://github.com/php/php-src/pull/2419, but it didn't quite work out because Datetime unfortunately supports __set_state().

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.