Edit report at https://bugs.php.net/bug.php?id=60873&edit=1
ID: 60873
Comment by: jglover at wilanddirect dot com
Reported by: kavi at postpro dot net
Summary: some inspections of DateTime member variables cause
creation, can break asserts
Status: Open
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 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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2013-07-09 10:41:00] hanskrentel at yahoo dot de
> DateTime objects have a timezone_type member variable.
This must be a non-permanent member (aka a variable property like any
PHP object offers if you set those).
The PHP documentation fosters this assumptions because for DateTime no
public properties are documented. So none are defined. If you enable
error reporting to the highest level in your example, I bet PHP
complains about undefined properties (which are non-fatal).
As you have reported this as a bug:
Please outline why you expect DateTime having some defined
(non-variable) properties when those aren't given for the class reflection?
Reflection shows you can't expect those members to be defined by default:
https://eval.in/private/2760b020207190
Class [ <internal:date> class DateTime ] {
...
- Static properties [0] {
}
...
------------------------------------------------------------------------
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
