Prevent comparisons between Time and TimeDelta from succeeding. - #10652

This has made me think about what should happen when passing a Time subclass into Time. Previously the subclass would come out directly, which is definitely wrong. But my intuition is that you would get back out the same moment(s) of time but represented in a pure Time object. E.g. we have a subclass of Time called CxoTime for Chandra ops work. One should be able to do:

Time(CxoTime('2020:001'))

Enabling this behavior would probably mean taking out the init handling in __new__ (which I put into #523) and doing something more like a4b8041 in #523. And you would need to have some special handling to specifically exclude subclasses of TimeDelta in the Time initializer.

Anyway, I'm OK with merging this basically as-is, but with a caveat of adding an API change entry noting that Time and TimeDelta can no longer be initialized from sub-classes. We could add a placeholder issue to rework the initialization to allow init from an "appropriate" subclass.

@taldcroft - yes, I agree, one would expected Time(TimeSubClass(...)) to work, just like Quantity(Angle(...)) returns a Quantity. It would also be solved if we restructured to have a TimeBase class of which both Time and TimeDelta are subclasses - see #6828 (comment)

One thing regarding the API change: that is nominally not OK for 4.0.2 -- though I guess the current behaviour for the initializer is somewhat of a bug.

Yeah, that TimeBase idea is good.

I guess there are two options:

• Backport this and make the nominal bug fix available for 4.0.x, 4.1.x, introducing a change that might break existing code.
• Only put this into 4.2.

I feel like this bug is not so critical and would be inclined to only putting it into 4.2. The API says that you can always initialize a Time object with another Time object, so I think that fixing the current incorrect behavior for subclasses needs to be in a feature release.

Yes, let's go for 4.2; it is not like we've noticed the bug for a couple of years!

Rebased. And raised #10654 to remind us of the subclass issue and the idea of a TimeBase superclass.

No longer necessary, as the issue is fixed (by #10656)