#40691 [Opn->Asn]: Incorrect results of DateTime equality check
ID: 40691
Updated by: derick@php.net
Reported By: hans at velum dot net
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: Gentoo Linux
PHP Version: 5.2.1
-Assigned To:
+Assigned To: derick
New Comment:
I am not sure it is even possible to overload the == operator here, but
I can check that. However, the comparison of unix timestamps is still
the way to go for now.
Previous Comments:
------------------------------------------------------------------------
[2007-03-04 20:40:49] hans at velum dot net
I maintain that this is counter-intuitive behavior. Do any other
built-in classes have this same comparison "feature" where they always
return TRUE when checked for eqaulity? If you truly believe this is
bogus, then this is a problem that must be addressed in the
documenation (which incidentally is basically horrible for the DateTime
class). It is simply not acceptable behavior to have a == comparison
between ANY DateTime object return TRUE.
This type of inconsistent & incoherent behavior in the PHP core is why
PHP maintains a poor reputation for OO development. It would be a huge
help to the community if these core classes worked in a predictable
manner, or at *least* if their unpredictable behavior were addressed by
documentation.
------------------------------------------------------------------------
[2007-03-04 18:34:12] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
This is not a bug. The date extension does not provide (or is intended)
for the purpose of comparing two date objects. You could have the same
date in the object by different properties initialized due to the way
the object was created.
As I've said earlier the most reliable way to compare two dates would
be
to convert them to unix timestamps and then compare the two.
------------------------------------------------------------------------
[2007-03-03 21:36:07] dzuelke at gmail dot com
hans at velum dot net is correct, I just stumbled over the same issue.
It definitely smells like a bug, nothing bogus here. The stored date is
a property of the object, but not compared properly as it should
according to the rules described at http://php.net/manual/en/
language.oop5.php. Probably because it's not possible to pull the
individual parts of a date (day, month, year etc) from a DateTime
instance, but that's a different story...
------------------------------------------------------------------------
[2007-03-03 19:47:15] hans at velum dot net
This is not bogus. Maybe "won't fix" but definitely not bogus.
Please note that I am quite familiar with object comparison in PHP. The
documenation says: "When using the comparison operator (==), object
variables are compared in a simple manner, namely: Two object instances
are equal if they have the same attributes and values, and are instances
of the same class."
Indeed, AS I POINTED OUT IN THE DESCRIPTION, other built-in objects in
PHP demonstrate the correct/expected behavior:
$a = new Exception("foo");
$b = new Exception("bar");
$c = new Exception("foo");
var_export($a == $b); // Outputs: FALSE
var_export($a == $c); // Outputs: TRUE
A DateTime object have very obvious properties (namely the date/time
value contained, possibly time zone of other info specified). The
equality check (NOT IDENTITY CHECK) should be comparing those values,
as apparently it does for Exception.
------------------------------------------------------------------------
[2007-03-03 15:55:40] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
Read on object comparison in PHP, what you are attempting will not
work.
if you want to compare 2 dates, convert them to unix timestamps first.
------------------------------------------------------------------------
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
http://bugs.php.net/40691
--
Edit this bug report at http://bugs.php.net/?id=40691&edit=1
Thread (9 messages)