ID: 40691 Updated by: [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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
