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:

stamp = datetime_helpers.DatetimeWithNanoseconds.from_rfc3339("2016-12-20T21:13:47.123456789Z")
dt = stamp.tzinfo.localize(datetime(2020, 1, 1))

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

CC: @geofft