Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <F5.B8.30612.3813BE54@pb1.pair.com>
To: internals@lists.php.net
Date: Sun, 04 Mar 2007 15:52:16 -0500
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: DateTime object equality
From: hlellelid@php.net (Hans Lellelid)

Hi all,

DateTime equality (not identity) appears to be broken.  I've created a
ticket for this issue (http://bugs.php.net/bug.php?id=40691), which
keeps getting marked as bogus by Ilia.  This may be a more appropriate
issue to raise on list, as I seem to be having both a very hard time
making my point about the inconsistency of the behavior and a very hard
time being convinced that this is not a bug (at *least* a documentation
problem, if nothing else) :)

The basic problem is that a [non-identity] comparison (==) of *any*
DateTime object with any other DateTime object will return TRUE.  Now, I
admit that I know little about the underlying layer, but as a developer
the DateTime object has a very clear set of properties (namely
date/time, maybe time zone) that I would expect would be compared by a
== equality check.

$d1 = new DateTime("2001-01-01");
$d2 = new DateTime("2007-02-28");
var_export($d1 == $d2); // Ouputs: TRUE


This always-return-TRUE behavior is extremely counter-intuitive.  It
also appears to be very exceptional in the PHP core classes.
Admittedly, I haven't looked through SPL, but the Exception object
provides a perfect example for what I would expect (based on the text in
the PHP manual about object comparison):

$a = new Exception("foo");
$b = new Exception("bar");
$c = new Exception("foo");

var_export($a == $b); // Outputs: FALSE
var_export($a == $c); // Outputs: TRUE

Obviously stdClass and user-defined classes exhibit this same behavior
of testing the object properties -- just as I'd expect from the
description in the manual.

Is this DateTime comparison behavior actually intended to be different
from everything else?  If there's some reason that DateTime object
properties cannot be compared to each other, wouldn't it be more
appropriate for them to always return FALSE ?

Thanks,
Hans