php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #60873 some inspections of DateTime member variables cause creation, can break asserts
Submitted: 2012-01-24 22:19 UTC Modified: 2017-01-17 07:02 UTC
Votes:22
Avg. Score:3.8 ± 0.8
Reproduced:20 of 20 (100.0%)
Same Version:8 (40.0%)
Same OS:0 (0.0%)
From: kavi at postpro dot net Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.3.9 OS: n/a
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: kavi at postpro dot net
New email:
PHP Version: OS:

 

 [2012-01-24 22:19 UTC] 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-09 10:41 UTC] 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] {
  }

  ...
 [2013-07-09 13:42 UTC] 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 19:08 UTC] 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 23:19 UTC] 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-10 00:59 UTC] kavi at postpro dot net 
The undocumented member variables are causing strict equality comparisons to fail.
 [2013-07-17 15:19 UTC] 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.
 [2017-01-17 07:02 UTC] heiglandreas@php.net
-Status: Open +Status: Not a bug
 [2017-01-17 07:02 UTC] heiglandreas@php.net 
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.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Nov 21 08:00:01 2025 UTC