Re: isEqual: and hash in NSDate

[Jeremy Bettis]

----- Original Message ----- 
From: "Adrian Robert" <address@hidden>
To: "Jeremy Bettis" <address@hidden>
Cc: <address@hidden>
Sent: Friday, July 22, 2005 9:57 AM
Subject: Re: isEqual: and hash in NSDate

> This really seems like a hack (not that it's any worse than the current 
> state :).  Couldn't the implementations of -hash and -isEqual be aligned 
> without this loss of information?  E.g. something like [warning, sloppy 
> first-attempt code here]:

Actually it is impossible to have isEqual: use an epsilon of any kind, and 
have hash work.

Since for any implementation (other than returning a constant for -hash) 
there would be some 2 dates where date1 - date2 < epsilon but hash(date1) != 
hash(date2).

I just think it is more important to have 1.001 == 0.999 then to have 1.001 
== 1.999, or even 1.499 == 1.501.  Even all of these are < 1 second apart, 
the first case was the real intent.  The point is to overcome floating point 
rounding error, not to have fuzzy equals.  I am sure that if NSTimeInterval 
was a fixed point type this code would never have been written.

Also, look at the documentation of Openstep:
> - (BOOL)isEqualToDate:(id)anotherDate
>
> Returns YES if the two objects compared are NSDate objects and are exactly 
> equal to each
> other, NO if one of the objects is not of the NSDate class or if their 
> date and time values
> differ. This method detects subsecond differences between dates. If you 
> want to compare
> dates with a less fine granularity, either use timeIntervalSinceDate: to 
> compare the two dates
> or use NSCalendarDate objects instead.
>
> Copyright © 1997 Apple Computer, Inc.

After reading that I am tempted to change isEqual to compare dates to 0.001 
seconds instead of 1 second.