Edit report at https://bugs.php.net/bug.php?id=60873&edit=1
ID: 60873
User updated by: kavi at postpro dot net
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:
>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.
Previous Comments:
------------------------------------------------------------------------
[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] {
}
...
------------------------------------------------------------------------
[2012-01-24 22:19:26] kavi at postpro dot net
Description:
------------
DateTime objects have a timezone_type member variable. This appears to differ
based on whether the timezone was set by passing a DateTimeZone object to the
DateTime constructor vs the constructor parsing it out of a string. The
timezone_type member variable is not mentioned anywhere in the documentation,
nor
is this behavior.
Further, inspecting DateTime objects with print_r and other interrogations can
cause the timezone_type properties to be created. Equality operator
comparisons
still work when timezone_type properties created and are different, but isEqual
in
SimpleTest (for example) does not, nor presumably will other object comparisons
which don't use what I imagine to be DateTime's overloaded comparison operators.
Please document the timezone_type member variable of DateTime and address the
unexpected behavior of member variable creation upon inspection.
Test script:
---------------
<?php
$a = new DateTime('2010-01-01 08:45:00', new DateTimeZone('UTC'));
$str = $a->format(DateTime::ISO8601);
$b = new DateTime($str, new DateTimeZone('UTC'));
echo "\n";
echo "a->timezone_type: " . $a->timezone_type . "\n";
echo "b->timezone_type: " . $b->timezone_type . "\n";
echo "\na: " . print_r($a, true) . "\n";
echo "\nstr: $str\n";
echo "b: " . print_r($b, true) . "\n";
echo "a->timezone_type: " . $a->timezone_type . "\n";
echo "b->timezone_type: " . $b->timezone_type . "\n";
$eq = ($a == $b);
echo "\na == b: $eq\n";
Expected result:
----------------
$ php test.php
a->timezone_type: 3
b->timezone_type: 1
a: DateTime Object
(
[date] => 2010-01-01 08:45:00
[timezone_type] => 3
[timezone] => UTC
)
str: 2010-01-01T08:45:00+0000
b: DateTime Object
(
[date] => 2010-01-01 08:45:00
[timezone_type] => 1
[timezone] => +00:00
)
a->timezone_type: 3
b->timezone_type: 1
a == b: 1
Actual result:
--------------
$ php test.php
a->timezone_type:
b->timezone_type:
a: DateTime Object
(
[date] => 2010-01-01 08:45:00
[timezone_type] => 3
[timezone] => UTC
)
str: 2010-01-01T08:45:00+0000
b: DateTime Object
(
[date] => 2010-01-01 08:45:00
[timezone_type] => 1
[timezone] => +00:00
)
a->timezone_type: 3
b->timezone_type: 1
a == b: 1
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=60873&edit=1
