MultiMap tests failing in java-support-v7-multi tests

The issue exposed here is that equality checks are used as part of, for example, ArrayList.contains() and the function of these MultiMap classes... so you're using equality whether you know it or not, if you put time objects into those collections. I guess I can't really see why you normally would do that with a time object, so that probably explains why we haven't seen other effects so far.

I think whoever wrote these tests originally used the Joda-Time objects mainly because they had a pretty rich type hierarchy, not because it was a plausible use case for the collections otherwise.

My recollection is that equality checks don't work with the new time objects and so I moved off of that everywhere I ran into it, or altered the checks to translate into explicit longs for the checks.

A Joda-Time Instant is always associated with UTC time zone, so this can be fixed by forcing the other created "now" to be associated with, say, California.

Commit 187fbb2c0aedef825788b027ba48786e5df3b19c fixes

This only applies to the maintenance branch; in the master branch for v4 we have moved away from Joda-Time and I suspect the comparison rules around the new types are a little different.

On reproducing the second failure: it seems like this is intermittent, as of course the second time we create one of these objects a millisecond may have passed. I am going to assume for now that both issues are the same.

On that last sentence: I think that while it might be nice for the Jenkins test VMs to have a predictable default TZ (here, it looks like the new machines have TZ=UTC) our tests should never assume that.