[jerf]

The problem isn't that you can't define an operator that will perform some boolean operation akin to equality on the values, the problem is that you can't define a universally agreed upon one. There's many sensible options (round to nearest, truncate, refuse entirely, and this is the start of the list not the end). The problem isn't a lack of options but an embarrassing surfeit of them. It's not that there aren't any answers, it's that there isn't an answer.

Moreover, there isn't anything intrinsically wrong with that. To go one "why" deeper, the problem is in the human brains that insist that such an operator simply must exist. How can we not do equality on times and dates? To which the answer is that your incredulity isn't really relevant and certainly doesn't create a universal answer.

Perhaps one "why" below that is a shallow understanding of operators in general, as Spivak references in a, err, nephew post of this one. If your concept of equality is that it was handed down from on high by your fourth grade teacher, you may have trouble dealing with the fact that there's really nothing special about it from a programming perspective, and programming routinely uses multiple concepts of "equality" even before we get into fundamentally ambiguous type comparisons! For instance, == vs. === in Javascript is two right there. Arguing about which is "the" equality operator is fundamentally flawed on the grounds that there really isn't such a privileged position of "the" equality operator to be occupied in the first place. We define many equality-like operators all the time, suitable for whatever local needs we have, and while there are certainly some that are more "equality-like" than others there is even so quite a few to chose from.

The ambiguity must be embraced and dealt with... or you will experience the implacable, impersonal engineer consequences of failing to do so, whatever those consequences may be for you in your particular situation.