8000 Print incorrect tz argument in error message by oscargus · Pull Request #25420 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

Print incorrect tz argument in error message #25420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 9, 2023
Merged

Print incorrect tz argument in error message #25420

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion lib/matplotlib/dates.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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}.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good, but perhaps more fundamentally is that dates.py does not define allowable units...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

tz = unit

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...



# Time-related constants.
Expand Down
0