Inconsistent hash equality behavior

[dmolesUC]

Given:

a = EDTF.parse!("1972%")
b = EDTF.parse!("1972-XX-XX")
h = {a => 1, b => 2}

Expected behavior:

1. a == b should be false
2. h.size should be 2
3. h[a] should be 1

Actual behavior:

1. a == b is false (correct)
2. h.size is 1 (incorrect)
3. h[a] is 2 (incorrect)

Notes:

• I can take a look at this some time in the next few weeks, just not right this minute

[inukshuk]

I think the best approach would be to hash the string representation if the Date is extend, otherwise fallback to Date's original #hash.

[dmoles]

That would work. Hash should be smart enough not to get keys mixed up just because two keys have the same hash, though. Looking at the Hash docs, the culprit is probably Date#eql?.

[inukshuk]

Yes, the hash is based on the underlying date instance. Many EDTF strings will fallback to the same date, e.g. in the example above it would be 1972-01-01T00:00:00Z I assume. So #eql? should react differently if the date is an extended date. Instead of checking all extended attributes manually, I was thinking it would be most consistent to render the EDTF string and simply defer to the implementation of String for equality (for greater/smaller it's probably better to stick with the underlying date instance). Of course rendering the string in #eql? could have major performance implications, so comparing the attributes may be better after all.