Hi Carlton, Sorry I didn't reply on the PR about advancing anything for 3.2. I ran out of capacity and at this late stage it is best to wait until 4.0 anyway.
I see that Aymeric is in favour of forging ahead to use zoneinfo in 4.0 as was my preference, but with the addition of an opt-out falling back to the deprecation shim. I'm also +1 for this approach, rather than an opt-in. I don't think it is a bad idea to promote this and get people to think about it sooner rather than later. For those with complex and/or significant use of pytz's API, there is then the option to opt-out and have another two or three releases to address the issue. Cheers, Nick On Tuesday, 5 January 2021 at 12:20:18 UTC wksch...@gmail.com wrote: > Just wanted to chime in with a +1 from a user in favor of moving away from > pytz. Doing so will be very helpful for frozen Python environments: > https://bugs.launchpad.net/pytz/+bug/1834363 > > On Sunday, January 3, 2021 at 2:43:01 AM UTC-6 Aymeric Augustin wrote: > >> Hi Carlton, >> >> IIUC-at-first-pass: your suggestion differs in jumping straight to the >> end-point with a fallback for those who need it. (In contrast to getting >> folks to opt-in early if they want it.) >> >> >> Indeed. The majority will switch when the default changes; better earlier >> than later. >> >> what did you think about allowing an early opt-in for Django v3.2? >> >> >> The more options we create, the more confusion we may generate e.g. when >> users try to understand release notes or to ask for support. This is why I >> tried to keep options to a minimum (1. initial situation, 2. target >> situation, 3. with shim) and to make as few users as possible go through >> option 3. >> >> Implementing USE_PYTZ_DEPRECATION_SHIM is Django 3.2 makes the situation >> a bit more complex, as the setting will mean "use pds instead of pytz" in >> 3.2 and "use pds instead of zoneinfo" in 4.0. We'd have four options >> instead of three. >> >> I'm pretty confident that the transition will go smoothly and I don't >> think the flaws in pytz are bad enough to warrant urgent action. As a >> consequence, offering opt-in in Django 3.2 doesn't seem all that valuable >> to me. >> >> I'm OK with starting the migration in one year in Django 4.0. I'm also OK >> with offering the opt-in in Django 3.2 if others have a different value >> assessment! >> >> Cheers, >> >> -- >> Aymeric. >> >> >> >> On 3 Jan 2021, at 09:12, Carlton Gibson <carlton...@gmail.com> wrote: >> >> Hi Aymeric. >> >> Thanks for inputting! >> >> I need to read in-depth what you’ve said here, but IIUC-at-first-pass: >> your suggestion differs in jumping straight to the end-point with a >> fallback for those who need it. (In contrast to getting folks to opt-in >> early if they want it.) This sounds better if we can. >> >> The Autumn hasn’t allowed time to make progress here but, what did you >> think about allowing an early opt-in for Django v3.2? (I’m not sure we have >> capacity to get the in in-time now anyway, so it may be moot.) >> >> Kind regards, >> Carlton. >> >> >> >> On Sat, 2 Jan 2021 at 10:29, Aymeric Augustin < >> aymeric....@polytechnique.org> wrote: >> >>> Hello, >>> >>> As the original author of support for timezone aware datetimes in >>> Django, I've been meaning to review this... for six months... Better late >>> than never I guess? >>> >>> In this discussion, we're assuming settings.USE_TZ = True. >>> >>> >>> The original design >>> <https://groups.google.com/g/django-developers/c/zwQju7hbG78>, which >>> still matches 80% of the current implementation, was very much based on >>> advice found in the documentation of pytz. This has three consequences: >>> >>> 1. By default, users manipulate aware datetimes in UTC, which limits the >>> breakage to cases where they explicitly switch to another timezone. This is >>> auditable e.g. "look for timezone.activate or timezone.override in your >>> code". >>> >>> 2. Django provides custom wrappers in order to take care of the pitfalls >>> of pytz automatically e.g. timezone.make_aware. Backwards-compatibility can >>> be implemented transparently there. >>> >>> 3. A strategy designed for migrating from pytz to zoneinfo should be >>> applicable to Django. >>> >>> >>> I'm seeing three areas that need care: >>> >>> A. APIs returning a tzinfo object, currently a pytz timezone (other than >>> UTC — we switched from Django's custom definition of the UTC tzinfo to >>> pytz' definition in the past without trouble). >>> >>> B. APIs returning aware datetimes, currently in a pytz timezone (other >>> than UTC). >>> >>> C. APIs performing datetime conversions in the database, which is >>> typically used for aggregating by day in a given timezone. This depends on >>> the timezone name. I think we're fine on this front since we're keeping the >>> same timezone names. >>> >>> So the primary concern is leaking pytz tzinfo objects (either directly, >>> or via aware datetime objects), to user code that requested it explicitly. >>> I may sound like I'm belaboring the point. However, I think we can make a >>> better backwards-compatibility decision with an accurate estimate of the >>> extent of the breakage. >>> >>> >>> Django currently references pytz in the following places: >>> >>> - timezone.get_default/current_timezone => see case A above. >>> - timezone.get_default/current_timezone_name => shouldn't be an issue >>> since time zone names don't change. >>> - BaseDatabaseWrapper.timezone => for timezone conversions in Python >>> code via make_aware / make_naive; see case B above. >>> - BaseDatabaseWrapper.timezone_name => for timezone conversions in the >>> database via database-specific SQL functions; see case C above. >>> >>> With SQLite, the SQL conversion functions are implemented in Python and >>> use pytz, but the end result is the same. >>> >>> >>> My suggestion would be: >>> >>> - Switch everyone to zoneinfo (or backports.zoneinfo) by default in 4.0 >>> - Provide a temporary, immediately deprecated setting >>> USE_PYTZ_DEPRECATION_SHIM in 4.0 and remove it in 5.0 >>> >>> Why? >>> >>> - Most users don't use timezone.activate, timezone.override, or the >>> DATABASES.TIME_ZONE setting to get aware datetimes in a timezone other than >>> UTC for the purpose of doing datetime arithmetic in local time. Let's keep >>> the upgrade instructions simple for the majority of users! "If you don't do >>> anything fancy with timezones, you don't need to worry about this!" >>> >>> - But some users need a more gradual path, especially those with large >>> codebases. Conscious use of pytz_deprecation_shim looks like the best plan >>> for them. Since it isn't easy to monkey-patch, let's instruct them to set >>> USE_PYTZ_DEPRECATION_SHIM = True so they can upgrade now and fix >>> deprecation warning later. This would be Paul's pull request >>> <https://github.com/django/django/pull/13073>, but conditional on the >>> setting. >>> >>> I considered using "can we import pytz_deprecation_shim?" as a signal >>> instead of "is USE_PYTZ_DEPRECATION_SHIM set?" but this wouldn't work well >>> if pytz_deprecation_shim becomes an indirect dependency. Then shims could >>> get accidentally activated and the user wouldn't have a good solution. >>> >>> >>> I hope this helps! >>> >>> -- >>> Aymeric. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/1AA84619-74BA-4A7D-A5A8-DC7210885BE9%40polytechnique.org >>> >>> <https://groups.google.com/d/msgid/django-developers/1AA84619-74BA-4A7D-A5A8-DC7210885BE9%40polytechnique.org?utm_medium=email&utm_source=footer> >>> . >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAJwKpyQrd7ueMfpuM-HkPUWCMjjpn2hTFpfz5%3D5ckVzZx-JMyg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAJwKpyQrd7ueMfpuM-HkPUWCMjjpn2hTFpfz5%3D5ckVzZx-JMyg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f0a6bad7-1b35-47e7-885d-904e662a5befn%40googlegroups.com.
