Add __hash__ method to Time class

The Time class should contain the __hash__ method. This will allow it to be used with other functions that require it such as functools.lru_cache.

Here is an example implementation:

     def __hash__(self):
         return hash((self.whole, self.tt_fraction))

Here is a link to what was done for AstroPy: https://github.com/astropy/astropy/pull/8912/files

[brandon-rhodes]

So I agree about the sum, that makes sense - would the key need to be rounded to some number of digits? All of the articles I have seen make me nervous about using a floating point key, and I don’t know all the ramifications.

Yes, I often take several tries to get floating point reasoning right.

Rounding seems to only make floating point problems less frequent, rather than solving them. If you round a 16-digit number to 14 digits, for example, you now hide 9,999 out of 10,000 cases where a difference could be noticeable. But in that last case, where one 14-digit number ends and the next one begins, it’s the full noise in the 16 digits of precision that will determine which way a number rounds. So I tend to avoid rounding since that rare case will still come back to cause problems for a test or a user someday.

But implicit rounding will occur here in any case because extra digits in the fractional part will disappear when combined with the whole part of the date. I guess I’ll implement it and see if it ever causes problems.

[brandon-rhodes]

True, but it works if you provide floats that in fact add to the same number 😃

from skyfield.api import load, T0, Time
ts = load.timescale()
t0 = Time(ts, 2451545.5, 1.1)
t1 = Time(ts, 2451545.6, 0.9999999999068678)
print(t0.whole, t0.tt_fraction)
print(t1.whole, t1.tt_fraction)
print(t0 - t1)
print(t0 == t1)

But equality is indeed a problematic concept when dealing with floats. One way it could cause problems here is that two different Time objects, like the two we have created here, might be equal yet could give a slightly different coordinate when asked for a satellite or planetary position, because the two floats of which the time is composed could cause different rounding down inside the computation, even though the two floats might represent the same sum. So two times that are “equal” could produce coordinates that are different.

In any case: one possibility would be to hash the sum currently returned by the .tt attribute (which used to be the real value of the time, before I decided to add more digits with this split representation). In the vast majority of cases the hash will come out different for different times. Only for very closely spaced times would they hash the same and have to fall through to comparison. Does that sound like a reasonable first approach?