Bug #49382 [Com]: can't access DateTime->date
[email protected] ("weirdan at gmail dot com")
| Newsgroups | php.bugs |
|---|---|
| Message-ID | <[email protected]> |
Edit report at https://bugs.php.net/bug.php?id=49382&edit=1 ID: 49382 Comment by: weirdan at gmail dot com Reported by: klawd at kamundo dot de Summary: can't access DateTime->date 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: > 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 Previous Comments: ------------------------------------------------------------------------ [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 ... ------------------------------------------------------------------------ [2015-12-23 04:03:32] 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. http://stackoverflow.com/questions/34427627/very-interesting-behavior-of-a-datetime-object-and-access-to-its-elements-bi ------------------------------------------------------------------------ [2014-12-08 17:48:27] 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. ------------------------------------------------------------------------ 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