stdlib zoneinfo support

[nikolaik]

Have you considered adding support for https://docs.python.org/3.9/library/zoneinfo.html in some way?

There are tree approaches that come to mind.

1. Replace all of pytz with zoneinfo equivalents (optionally installing the backports.zoneinfo module).
2. Add support for zoneinfo alongside pytz, allowing ZoneInfo as field values. Adding a use_pytz as a new parameter on TimeZoneField, defaulting to False which would start returning ZoneInfo objects from db instead of pytz ones. Deprecating pytz support.
3. Support for pytz and zoneinfo equally with use_pytz parameter defaulting to True. Not deprecating pytz.

Thanks for a great package btw, keep up the good work!

[jensenbox]

Now that Django 4.0 is out I think there might be addition pressure to port away from pytz

This might help: https://pytz-deprecation-shim.readthedocs.io/en/latest/index.html

[mfogel]

Thanks for bringing this up @nikolaik. I will probably try to follow your second option more than the other two. Here's the general release schedule I've got in my head:

• within a week: another minor version release
  • no zoneinfo logic
  • last release for django 2.2, 3.0, 3.1
• within a month: a major version release
  • add support for zoninfo objects, but have them disabled by default.
  • drop support for old djangos, pythons that get in the way of zoneinfos
  • community uses and tests the zoneinfo mode, we hopefully get the bugs flushed out
• within a year: a major version release
  • switch default to zoneinfo, pytz still available by setting a config option
• within 5 years: a major version
  • drop support for pytz mode

Hopefully there's good compatibility between the strings used by zoninfo and pytz. If not perhaps this project can provide some scripts or examples to help users migrate their databases.

[nikolaik]

Hopefully there's good compatibility between the strings used by zoninfo and pytz. If not perhaps this project can provide some scripts or examples to help users migrate their databases.

For our use we ended up adding a vendored version of pytz.common_timezones when migrating to zoneinfo from pytz. Otherwise, things looks good so far.

[rawbeans]

• drop support for old djangos, pythons that get in the way of zoneinfos

Why would you drop support for old Django versions? What about Django 2.2+ would prevent someone from using zoneinfo?

[mfogel]

good point @rawbeans , if there's no API changes it should be fine to continue to support django 2.2

[mfogel]

To those following this thread: as far as deprecating and eventually dropping support for pytz altogether, I'm now leaning on mimicking django's strategy rather than what I described above. (Most of this idea and implementation thanks to @tim-schilling) Specifically

• there will be a use_pytz optional keyword, that's similar to django's new setting USE_DEPRECATED_PYTZ
• on django <= 3.x, use_pytz will default to True
• on django >= 4.x, use_pytz will default to the value of the USE_DEPRECATED_PYTZ setting, which itself defaults to False

Then since django is planning to drop support for pytz altogether in the 5.x line, once this package drops support for django 4.x it can also drop support for pytz as well. That would tentatively be in April 2026 or so, according to django's roadmap.

Thoughts / feedback welcome

[mfogel]

I just merged #81, and released version 5.0 to pypi which includes zoneinfo support, 90% thanks to @tim-schilling 's work on #80. Please give it a try when you get a chance, and open bug reports for any issues you run across. Thanks & cheers