I agree that converters shouldn't fail, but I think with these changes they give very misleading/nonsense answers which is worse! Maybe I'm missing something though - is there a larger motivation to make this change other than just "converters shouldn't fail"?

We have times where an axes is dates but during draw gets temporarily set back to default limits of zero and one. This errors out. See#15409 for the latest incantation of this problem but there have been quite a few.

This suggestion does return nonesense if the user somehow uses the wrong x/ylimits or puts bad data on the date axis. Right now we error if the data is bad enough (ie x<1) but not if it’s sort of bad (x>1).

See#15148 for a different approach. But we really can’t be in a position where a unit converter throws errors on zero.

Of course the other option is to change the epoch so zero isn’t year 0001. See#15008.

This can invert the direction of the axis, I don't recall off the top of my head how 'sticky' that is.

If the problem is the default [0, 1], how about changing that to [1, 2] or [1, 10], or ...?

The 0-1 default is the default for all axes. I guess we could change that, but folks who make an axes and position text on it by data position will find their code broken.

I don't like the nonsense aspect of this solution; my reaction is the same as@dstansby's, that this cure is worse than the disease.

My strong preference is that we change the epoch.

I'll close this as a bit of a silly idea, however, I still think we should do#15008