Currently matplotlib defaults to using pytz for time zone support, I think that this should be dropped in favor of using dateutil.tz, which supports everything pytz does and more.
Case for dateutil
For starters, dateutil is already a dependency, so this removes rather than replaces a dependency. Additionally, the time zones dateutil provides properly implement the tzinfo protocol, while pytz uses a non-standard API that is famously confusing.
Generally matplotlib handles all this correctly internally, but this only breaks backwards compatibility insofar as users are actually taking the time zone they are getting and using it for something, and those people are getting an object with a famously confusing API (every time I talk about this I get people saying they've been doing it wrong, and even people who know how this works in general don't often understand the details well).
Case against dateutil
In favor of pytz, I'll say that it's a very "light" dependency in the sense that it's extremely widely used and is a hard dependency of other libraries like pandas that matplotlib users are likely to be installing anyway.
Additionally, currently pytz is faster than dateutil, and I think does a (somewhat) better job at memoizing function calls. This is something that I'm actively working on in dateutil, and I've already closed the gap in many areas (particularly dateutil.tz.tzutc(), which is very useful).
Summary:
In favor of dateutil:
Standard tzinfo interface
Support for fold
Already a dependency
In favor of pytz:
Faster
Wouldn't break backwards compatibility to keep it.
I'll also note that I'm only suggesting that matplotlib stop using pytz as its default timezone provider, not that all support for pytz be dropped. Users should still be able to supply datetime objects with any valid tzinfo and have matplotlib work properly.
@anntzer pytz zones are not interchangeable with standard tzinfo implementations, as I demonstrated in my original post, and some infrastructure may be needed to support them properly. I recommend dropping pytz as a dependency and scrub it from the library code, but continuing to test against it.
When I prepare the PR, I'll look into how much special-case code is necessary to support pytz-style zones and if it's a lot it might be worth discussing dropping explicit support for pytz, but there's at least a subset of operations that should probably be supported given how widely pytz is used.
One thing I'll note is that basically anything that operates entirely on the "absolute timeline" should be no problem, because for both pytz and dateutil you can do the exact same operations:
These aware-to-aware transformations are supported perfectly well by both pytz and dateutil. The problem comes with when you have "wall clock" operations, which comes up for example with rrule, where you are generating "wall times" and then localizing them to a given zone, see, for example, this function, which assumes anything implementing a localize function implements a pytz-like interface.
Activity
tacaswell commented on Feb 13, 2018
I am 👍 on this and dropping pytz as a run-time dependency, but we should keep a few tests using it.
anntzer commented on Feb 14, 2018
Do we even need to? Aren't tz implementations simply supposed to inherit https://docs.python.org/3/library/datetime.html#datetime.tzinfo and that should be the ground truth?
pganssle commented on Feb 14, 2018
@anntzer pytz zones are not interchangeable with standard tzinfo implementations, as I demonstrated in my original post, and some infrastructure may be needed to support them properly. I recommend dropping pytz as a dependency and scrub it from the library code, but continuing to test against it.
When I prepare the PR, I'll look into how much special-case code is necessary to support pytz-style zones and if it's a lot it might be worth discussing dropping explicit support for pytz, but there's at least a subset of operations that should probably be supported given how widely pytz is used.
One thing I'll note is that basically anything that operates entirely on the "absolute timeline" should be no problem, because for both pytz and dateutil you can do the exact same operations:
These aware-to-aware transformations are supported perfectly well by both pytz and dateutil. The problem comes with when you have "wall clock" operations, which comes up for example with rrule, where you are generating "wall times" and then localizing them to a given zone, see, for example, this function, which assumes anything implementing a localize function implements a pytz-like interface.