Bug #60873 [Opn->Nab]: some inspections of DateTime member variables cause creation, can break asserts

Edit report at https://bugs.php.net/bug.php?id=60873&edit=1 ID: 60873 Updated by: heiglandreas@php.net Reported by: kavi at postpro dot net Summary: some inspections of DateTime member variables cause creation, can break asserts -Status: Open +Status: Not a bug Type: Bug Package: Date/time related Operating System: n/a PHP Version: 5.3.9 Block user comment: N Private report: N New Comment: The added properties have nothing to do with strict comparison failing. A DAteTime with Timezone UTC is something different than a DateTime with an offset of 00:00. Even though the timestamp might be the same. That's what the "==" operator checks. Both objects represent the same point in time so they will be said to be equal. That the properties are added during a print_r or var_Dump is known, but those properties should not be used to access internal informations. You should only use the appropriate ssetters and getters! As this isn't a bug in PHP and it also targets an unsupported version of PHP I'm closing this. Previous Comments: ------------------------------------------------------------------------ [2013-07-17 15:19:36] jglover at wilanddirect dot com "The undocumented member variables are causing strict equality comparisons to fail." This is exactly the problem we are encountering that led me to this bug report. It is certainly a problem when the equality comparisons fail. ------------------------------------------------------------------------ [2013-07-10 00:59:42] kavi at postpro dot net The undocumented member variables are causing strict equality comparisons to fail. ------------------------------------------------------------------------ [2013-07-09 23:19:11] hanskrentel at yahoo dot de > Because the current behavior doesn't make sense, and the expected behavior does. So are you trying to sell me a self-fulfilling prophecy as an argument? > Furthermore [...] the actual bug is that DateTime objects behave differently in some situations That statement is wrong. If you treat the DateTimne objects the same, they behave the same. Still yet I can't see how that answers my previous question how one can expect an undefined property to exist on an object as it's undefined. And variable properties are in PHP since version 3. So if you find some property on an object you wonder about, first find out where the property originates from. Is it a default one (term leaned from PHP ReflectionObject) or has it been added later (variable property). For the later ones, it must not have been added by the object itself so can as well be added by other code that has touched the object from the outside. In your example code print_r is adding those variable properties for example. But I can easily write a function that adds those properties as well and this would be completely bug-free PHP code. ------------------------------------------------------------------------ [2013-07-09 19:08:43] kavi at postpro dot net Furthermore, and with the benefit of further coffee consumption, the actual bug is that DateTime objects behave differently in some situations depending upon how they are created, even if the date, time, and time zone they represent are identical. ------------------------------------------------------------------------ [2013-07-09 13:42:30] kavi at postpro dot net >Please outline why you expect DateTime having some defined >(non-variable) properties when those aren't given for the class reflection? Because the current behavior doesn't make sense, and the expected behavior does. ------------------------------------------------------------------------ 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=60873 -- Edit this bug report at https://bugs.php.net/bug.php?id=60873&edit=1