This seems like the wrong place to decide whether or not this is a timedelta. 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 to timedelta.

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 in this comment. timedelta is a weird animal in that you normally don't have separate units for x and delta-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) datetime could be used as a width in rect, which is just as wrong as timedelta failing to work (and this does not 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 of x or delta-x.

Another thing to note about this solution is that ideally the way this would work is that height and width would apply to the values in the initial units / types, if possible.

Consider that if the plot's width is calculated by adding width to dt_begin, you automatically get the ability to add dateutil.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.