#40691 [Asn->Csd]: Incorrect results of DateTime equality check
| From: | mike@php.net | Date: | Mon, 05 Mar 2007 14:06:30 +0000 |
| Subject: | #40691 [Asn->Csd]: Incorrect results of DateTime equality check | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-109923@lists.php.net to get a copy of this message | ||
ID: 40691
Updated by: mike@php.net
Reported By: hans at velum dot net
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: Gentoo Linux
PHP Version: 5.2.1
Assigned To: derick
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
------------------------------------------------------------------------
[2007-03-05 12:04:02] hans at velum dot net
Thanks, Derick!
------------------------------------------------------------------------
[2007-03-05 09:59:48] derick@php.net
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.
------------------------------------------------------------------------
[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...
------------------------------------------------------------------------
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