-
Notifications
You must be signed in to change notification settings - Fork 448
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.
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
Drop pytz as a dependency #716
Comments
I'll note that in a search on github, the only references to |
I would say that removing |
As of 58de834, |
In preparation of removing the hard dependency on pytz Refs python-babel#716
@pganssle @mitsuhiko Following #852 (to be merged for Babel 2.10), |
In preparation of removing the hard dependency on pytz Refs #716
May I ask for an update on this issue? With Django 4.x deprecating pytz in favour of zoneinfo and with Django 3.x losing LTS this year, we are looking to remove the pytz dependency altogether to avoid (accidental) incompatibilities when passing datetimes between libraries. It currently seems that Babel would be blocking that. |
I don't have an update here but I would be curious if there is an actual risk of this happening. In theory the tzinfo interface did not change (at least from my understanding) so the objects should work interchangeably. |
In theory, it should indeed not matter if everyone adheres to the However, there are already some incompatibilities in timezone data, since the Would it be okay if I send in a PR to remove the hard |
@ds-cbo A pull request is very welcome. |
The latest version of Babel has an issue that causes an error when "make html" is run in some cases. Installing pytz seems to fix it, but this issue makes it seem like that dependency is undesirable: python-babel/babel#716. Pinning to Babel 2.11.0 for now avoids local build issues.
The latest version of Babel has an issue that causes an error when "make html" is run in some cases. Installing pytz seems to fix it, but this issue makes it seem like that dependency is undesirable: python-babel/babel#716. Pinning to Babel 2.11.0 for now avoids local build issues.
The latest version of Babel has an issue that causes an error when "make html" is run in some cases. Installing pytz seems to fix it, but this issue makes it seem like that dependency is undesirable: python-babel/babel#716. Pinning to Babel 2.11.0 for now avoids local build issues.
Since the introduction of PEP 495,
pytz
's unusual API has become more of a liability than an asset. With the introduction of PEP 615 (the standard libraryzoneinfo
module), there is really no good reason to continue usingpytz
at this point, and it is probably a good time to transition away from it. This is one of the more popular projects usingpytz
, and I think it would be a good idea to start transitioning away.I will note that Stuart Bishop, author and maintainer of
pytz
, is planning to makepytz
a thin wrapper aroundzoneinfo
at some point, and so it is probably a good idea to get ahead of the curve on this.I took a quick look to see how easy it would be to do, and I found that the
pytz
-specific integration is a bit deeper than I had hoped, and a straightforward adoption ofzoneinfo.ZoneInfo
would run into the following problems:backports.zoneinfo
only supports Python 3.6+.get_timezone
function explicitly returnspytz
zones, which (as we noted), have a different API than standardtzinfo
zones.get_next_timezone_transition
function relies on private implementation details ofpytz
, and it is not possible to write analogous code forzoneinfo
, which stores transition information in opaque C structs. Presumably this will become a problem in the future whenpytz
becomes a thin wrapper aroundzoneinfo
anyway.I think that we can solve problem 1 easily enough by adding a compatibility function that uses
dateutil.tz
in Python 2.7 only —dateutil.tz
has similar functionality tozoneinfo.ZoneInfo
.Depending on how you feel about breaking changes and how much you intend to explicitly support the
pytz
interface, I think you can solve problem 2 with a thin wrapper class deprecating thepytz
interface, like this:Where
raise_pytz_warning()
would raise a warning telling people to stop callinglocalize
andnormalize
, as the wrapper class will be dropped in a future version.Problem 3 is the hardest to solve and also is likely to affect you regardless of whether or not you choose to adopt
backports.zoneinfo
. There's no public interface on any time zone provider that allows for this, so I think your options are:zoneinfo
for Python 3.10, and add it tobackports.zoneinfo
now.The text was updated successfully, but these errors were encountered: