Two objections:

1. Despite the superficial and subject matter similarities, I'm not convinced thattimedelta is necessarily best handled indates.py. Date-time instances are complicated because their natural domain is a line in a non-decimal, often non-monotonic number system with complicated unit system.timedelta specifically, because itonly handles durations whose length is invariant with translation along the number line, is effectively a convenience wrapper around an integer number of seconds, with almost none of the complexity ofdatetimes. If there's a general units framework, I thinktimedelta likely fits in there much better than lumping it in withdates.py. I'm open to being convinced thattimedelta works best indates.py

2. It's not clear to me why the base unit for this is ordinaldays. They don't really need to be compatible with how datetimes are handled, and the more natural base unit would be some unit like seconds, microseconds, nanoseconds, etc.np.timedelta64 has some complicated unit behavior, but the base type seems to be microseconds.

I think this has to be this way in order to be compatible with how we handle datetimes; the base unit has to the be the same if e.g. I want to plot something that has atimedelta width on adatetime axis.

@dstansby I think the question of having atimedelta width on adatetime axis was solved by#9072. That's very different from plotting atimedelta on adatetime axis.

The problem has come up again in#11290 - I see no reason to use ordinal days - we have to use something, and using ordinal days would make our lives much easier with respect to plotting widths/heights on datetime axes.

I haven't had a chance to really look at and grok how the units framework works. I suppose it's possible that units are inferred from type and that everything gets translated into a number under the hood and plotted on the same plot, in which context I guess definingany mapping fromtimedelta to that single number line is fine because these things shouldn't be plotted at the same time butmatplotlib isn't enforcing that in any way.

That said, from some preliminary tests, plotting arbitrary non-datetime points on a datetime axis currently fails with a message like:

ValueError: view limit minimum -4.95 is less than 1 and is an invalid Matplotlib date value. This often happens if you pass a non-datetime value to an axis that has datetime units

Sounds like it's a mix of the two, where youcould plot non-datetime values if you got them right (because it's not enforced), but it's unlikely enough to work that there's a dedicated error message for it.

I think the right course forward for#11290 is to finish the work started in#9072 of defining all spans asstart + span, such that types with relative but no absolute semantics or meaning (likedatetime.timedelta anddateutil.relativedelta) don't cause errors.

I have a religious objection to this test. I don't believe that the private interface should be explicitly tested like this (this is in factnot possible in less permissive languages). You can see the variousanswers on this SO thread for a list of reasons why not.

I would suggest implementing some part of the public interface that uses this_tdelta_to_ordinalf(dt) function and writing tests forthat.

I'll try and put a proper plotting test with timedeltas in.