Problem

As noted during the review of #27114, the current support of units in stackplot is subpar, particularly for the y axis.

For datetimes in particular, the implicit 0 of the API is problematic, introducing 1970-01-01 when that is not a relevant date.

Therefore I suggest allowing baseline to be not only the current supported string literals, but also a scalar value (or potentially an array, I guess) such that a "sensible" baseline can be provided for cases where 0 is not sensible. (even the other options for baseline assume you want your plot centered around 0... I'm not concerned about wanting "wiggle centered at 2023-02-28" or anything like that, that seems perhaps a bridge too far.)

I also think it is important to explicitly state that the y values are in delta units (similar to how we do for e.g. bar for the width parameter. This is already true in that adding actual datetime values will fail, but passing timedelta objects will work.

Finally, the cumsum call contains a promote_types(y.dtype, np.float32), which will fail for np.timedelta64 arrays (Edit, to be consistent with other points, clarified that I really meant timedelta instead of datetime64 here):

So either removing that or at least handling the error case is needed. It's not fully clear to me what we are guarding against there, as cumsum of integers is fine being integral, though I guess we could run into overflow issues? Passing datetime.timedelta as object arrays (or as lists which get turned into object arrays) will work and produce a plot, just without a sensible baseline, currently.

Proposed solution

No response