Print incorrect tz argument in error message #25420
Conversation
|
Anyone can merge post CI |
| @@ -230,7 +230,7 @@ def _get_tzinfo(tz=None): | |||
| return tzinfo | |||
| if isinstance(tz, datetime.tzinfo): | |||
| return tz | |||
| raise TypeError("tz must be string or tzinfo subclass.") | |||
| raise TypeError(f"tz must be string or tzinfo subclass, not {tz!r}.") | |||
There was a problem hiding this comment.
I think this is good, but perhaps more fundamentally is that dates.py does not define allowable units...
There was a problem hiding this comment.
Yes, there seems to be a bit of "abuse" of things. This line doesn't really look like one would hope for:
matplotlib/lib/matplotlib/dates.py
Line 1798 in 75a35e0
To me it seems like one is patching dates to, sort of, work with units. But then I have very limited insights into how the units do work.
There can for sure be better fixes for this, but this one the one I could add to at least improve the situation slightly...
My interpretation of the problem is that there is no checking for validity when setting the units. Then, when setting timezone through axis_date, whatever is set as self.units of the Axis is used and an AutoDateLocator is instantiated with that as tz...
PR Summary
Related to #25419.
It would have been slightly easier to realize that something surprising was going on if one could have seen the incorrectly passed
tzargument (which was not the one that a user would expect that they had just passed...).PR Checklist
Documentation and Tests
pytestpasses)Release Notes
.. versionadded::directive in the docstring and documented indoc/users/next_whats_new/.. versionchanged::directive in the docstring and documented indoc/api/next_api_changes/next_whats_new/README.rstornext_api_changes/README.rst