This sounds like a reasonable timeline to me. I think the breakage will be relatively small because I suspect many end-users don't really even know to use `normalize` in the first place, and when introducing the shim into a fundamental library at work I did not get a huge number of breakages, but I am still convinced that it is reasonably categorized as a breaking change.
I do think that there's one additional stage that we need to add here (and we chatted about this on twitter a bit), which is a stage that is fully backwards compatible where Django supports using non-pytz zones for users who bring their own time zone. I suspect that will help ease any breaking pain between 3.2 and 4.0, because no one would be forced to make any changes, but end users could proactively migrate to zoneinfo for a smoother transition. I think most of what needs to be done is already in my original PR, it just needs a little conditional logic to handle pytz as well as the shim. I am not sure how you feel about feature flags, but as a "nice to have", I imagine it would also be possible to add a feature flag that opts you in to `zoneinfo` as time zone provider even in 3.2, so that people can jump straight to the 5.0 behavior if they are ready for it. I should be able to devote some time to at least the first part — making Django compatible with zoneinfo even if not actively using it — but likely not for a few weeks at minimum. If anyone wants to jump on either of these ahead of me I don't mind at all and feel free to ping me for review. Best, Paul On 10/7/20 10:48 AM, Carlton Gibson wrote: > Hi Paul. > > Thanks for the input here, and for your patience > > > I am fairly certain this is going to be a tricky migration and will > inevitably come with /some/ user pain. I don't think this will be > Python 2 → 3 style pain, but some users who have been doing the "right > thing" with pytz will need to make changes to their code in the long > run, which is unfortunate. > > Looking at all the docs, your migration guide on > pytz_deprecation_shim, the example Kevin gave > <https://repl.it/@severian/pytzshim#main.py>, where we do some > arithmetic in a local timezone, and call `normalize()` in case we > crossed a DST boundary, there's no way we can do this without forcing > a breaking change somewhere. > > So, probably, I've been staring at this too long today, but I think we > should introduce the shim in Django 4.0. Django 3.2, the next major > release will be an LTS. If we hold-off introducing the change until > 4.0, we can flag it as a breaking change in the 4.0 release notes, > with big warnings, allowing folks extra time to hang out on the > previous LTS if they need it. > > What I wouldn't want to do is to bring the breaking change in in > Django 3.2, because we'll have a whole load of folks updating from the > 2.2 LTS at about the time when it goes End of Life, and with no > warning, that'd be a hard breaking change to throw on top of their > other issues. > > We'd keep the shim in place for the entire 4.x series, removing in > Django 5.0 as per the deprecation policy > <https://docs.djangoproject.com/en/3.1/internals/release-process/#deprecation-policy>. > > I think the advantages of doing it this way are two-fold: > > * We allow people to focus on the semantic breaking change (in folds) > separately from the code changes per se — the logic may have changed > slightly in these cases, but it'll still run. > * It looks easier to migrate Django's code vs branching on a new > setting. (I didn't think through exactly what that might look like, so > happy to see a PoC from anyone.) > > I'm more attached to the timeline (i.e. making the change after the > next LTS) than whether we use the deprecation shim or not, but can I > ask others to give this their thought too? > > Thanks again! > > Kind Regards, > > Carlton > > > -- > 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/ce04a6b7-4409-4b20-ba30-4cd64dc0cabfn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/ce04a6b7-4409-4b20-ba30-4cd64dc0cabfn%40googlegroups.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/e13e8ae2-5d43-e550-48a4-cb7ad6e699f6%40ganssle.io.
signature.asc
Description: OpenPGP digital signature
