This seems like the wrong place to decide whether or not this is atimedelta. Despite both being about time, I think durations and points in time are very different things and should follow different code paths. Most of the date-handling stuff is simply not applicable totimedelta.

how else would you compute widths? It is a similar problem to temperatures. You can't simply convert a 5 degrees C temperature change into Fahrenheit temperature change (a big annoyance of mine when reading news articles that blindly injects unit conversions)

@WeatherGod I expressed my reservations a bit more inthis comment.timedelta is a weird animal in that you normally don't have separate units forx anddelta-x, but in datetimes you do.

One problem with this as a solution to#4916 is that a corollary to#4916 is that (if I understand correctly)datetimecould be used as a width inrect, which is just as wrong astimedelta failing to work (and this doesnot fix that problem).

I don't know enough about the way the width processing and unit framework to know what the right seam is, but I would think that the right place to do the type check would be earlier in the pipeline, when you still know whether this is supposed to be units ofx ordelta-x.

Another thing to note about this solution is thatideally the way this would work is thatheight andwidth would apply to the values in the initial units / types, if possible.

Consider that if the plot's width is calculated by addingwidth todt_begin, you automatically get the ability to adddateutil.relativedelta.relativedelta objects as well (for example,relativedelta(weekday=MO(+3)) - the width being "from the initial value to three Mondays later). It's not high priority, but if you're solving this problem anyway, it's worth considering that leveraging the existing arithmetic framework for rich objects might be worth doing.

ooh, now that is an attractive option.