Time equality comparisons are possibly too precise
See original GitHub issueIn astro_metadata_translator I’ve been adding some tests to make sure that the end date of an observation comes after the start date of an observation. Sometimes DATE-END header is missing so the end date is derived by adding the exposure time to the start date. This is fine until biases are included which have 0.0 second exposures, whereupon the end date is now in the past.
$ python
Python 3.7.3 (default, Mar 27 2019, 16:54:48)
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from astropy.time import Time
>>> import astropy.units as u
>>> t1 = Time("2018-07-24T10:41:56.807015240")
>>> t2 = t1 + 0.0*u.s
>>> from astropy.time import TimeDelta
>>> t3 = t1 + TimeDelta(0.0*u.s)
>>> t3 == t1
False
>>> t2 < t1
True
>>> t1.jd2
-0.054203622508796234
>>> t2.jd2
-0.054203622508796345
>>> t3.jd2
-0.054203622508796345
i.e. if you add (at least on my Mac) 0 seconds to a Time the resulting time object is, in this case, 10 picoseconds behind the original time. This breaks my tests because the end date is not allowed to be behind the start date. I’m fixing the tests by converting the Time to a ISO string and then converting back to a Time object before doing the >= test but I’m wondering whether this behavior is deliberate or if no-one has ever tried it.
- Should
__eq__
be comparing floating point numbers to 0.0 without some form of precision check (math.isclose
?). - If a precision is specified for the
Time
should that be used in the equality? - If a time delta of 0 seconds is added to a
Time
should the newTime
go backwards in time? - Is
Time
meant to support picoseconds precision? If it isn’t then the equality test should take that into account. If it is then the above suggests it’s not.
Issue Analytics
- State:
- Created 4 years ago
- Comments:23 (23 by maintainers)
Top GitHub Comments
Looking at
np.isclose
, I’m a bit dubious of shoe-horning that to work forTime
sincertol
andequal_nan
are both not applicable in this case. I would instead suggest to have the__array_function__
override raise NotImplemented and tell the user to useTime.isclose
, which will have the proper documentation etc.p.p.s. That said, it would be good to have a version of
isclose
or so - I end up writing too many tests of the sort ofassert abs(t1 - t2) < 1 * u.ns
…