In 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 new Time 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.