Edit report at https://bugs.php.net/bug.php?id=49382&edit=1
ID: 49382
Updated by: [email protected]
Reported by: klawd at kamundo dot de
Summary: can't access DateTime->date
-Status: Re-Opened
+Status: Not a bug
Type: Bug
Package: Date/time related
Operating System: Debian GNU/Linux 5.0
PHP Version: 7.1
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2017-03-24 13:29:58] [email protected]
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().
------------------------------------------------------------------------
[2017-03-24 12:55:40] 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.
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
------------------------------------------------------------------------
[2017-03-24 06:18:56] [email protected]
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-01-11 17:14:40] [email protected]
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!
------------------------------------------------------------------------
[2016-07-06 10:42:25] 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
...
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=49382
--
Edit this bug report at https://bugs.php.net/bug.php?id=49382&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.