Most Java programmers know that there are four different ways to compare Java objects (==, equals(), the Comparable and the Comparator interface).
There is the reasonable assumption that when a.equals(b) is true, a.compareTo(b) is 0.
But what about the other way around? A trap that we fell into at Ness was that we took JodaTime DateTime objects, shoved them into a SortedSet and out came a list of sorted dates. But when looking for a specific date in a list created from the same objects, it was not found.
The trap is, that two DateTime objects representing the same instant in time return 0 when compared, but when tested for equality using equals() they return false. In our case, one object used the local time zone and the other uses UTC.
DateTime shares that peculiar property with a small number of other classes, for example BigDecimal from the JDK itself.
Tested using groovy:
groovy.grape.Grape.grab([group:'joda-time', module:'joda-time', version:'2.0'])
import org.joda.time.*
a = new DateTime().withZone(DateTimeZone.UTC)
b= new DateTime().withZone(DateTimeZone.forID("America/Los_Angeles"))
println a.equals(b)
println a.compareTo(b)
produces
false 0