You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From what I can tell, pytz is only used to access a UTC time zone, and to create fixed offsets in the tests. Both of these use cases are supported in the Python standard library datetime module in all supported versions of Python 3.
Since pytz is deprecated or semi-deprecated, it would be a good idea to remove the pytz dependency as soon as possible. It seems that the master branch has not dropped Python 2.7 support yet, so I think the prudent course of action would be to either drop Python 2.7 support entirely in the next release, and drop the pytz dependency along with it.
If you cannot drop Python 2.7 support, it's fairly trivial to write a UTC object for Python 2.7 compatibility, or you can add a 2.7-only dependency on python-dateutil to get access to dateutil.tz.UTC and dateutil.tz.tzoffset.
The only downside to dropping pytz is that if a user is counting on your methods generating datetime objects with pytz.UTC attached, because they are doing something like dt.tzinfo.localize(something). This is because pytz has its own non-standard time zone interface, and other tzinfo providers don't have the same API. This would only happen if someone is doing something like this:
It seems unlikely that anyone is counting on this, and it's easy enough to fix if they are, particularly for UTC objects.
If you are very worried about it, I have a pytz-deprecation-shim module that provides the same API as pytz, but can be used as a normal tzinfo, and raises deprecation warnings whenever the pytz-specific methods are used. I believe that is probably a heavier dependency than you need for these purposes (it also works in Python 2.7).
From what I can tell,
pytz
is only used to access aUTC
time zone, and to create fixed offsets in the tests. Both of these use cases are supported in the Python standard librarydatetime
module in all supported versions of Python 3.Since
pytz
is deprecated or semi-deprecated, it would be a good idea to remove thepytz
dependency as soon as possible. It seems that the master branch has not dropped Python 2.7 support yet, so I think the prudent course of action would be to either drop Python 2.7 support entirely in the next release, and drop thepytz
dependency along with it.If you cannot drop Python 2.7 support, it's fairly trivial to write a
UTC
object for Python 2.7 compatibility, or you can add a 2.7-only dependency onpython-dateutil
to get access todateutil.tz.UTC
anddateutil.tz.tzoffset
.The only downside to dropping
pytz
is that if a user is counting on your methods generatingdatetime
objects withpytz.UTC
attached, because they are doing something likedt.tzinfo.localize(something)
. This is becausepytz
has its own non-standard time zone interface, and othertzinfo
providers don't have the same API. This would only happen if someone is doing something like this:It seems unlikely that anyone is counting on this, and it's easy enough to fix if they are, particularly for UTC objects.
If you are very worried about it, I have a
pytz-deprecation-shim
module that provides the same API aspytz
, but can be used as a normaltzinfo
, and raises deprecation warnings whenever thepytz
-specific methods are used. I believe that is probably a heavier dependency than you need for these purposes (it also works in Python 2.7).CC: @geofft
The text was updated successfully, but these errors were encountered: