I agree with Adam. I've also left a small comment on the PR.
Paolo On Tue, Jan 12, 2021 at 5:59 PM Adam Johnson <m...@adamj.eu> wrote: > > I think it's worth merging into 3.2. The change is quite small, the potential > benefits are quite large, and some users live LTS to LTS so could be left > without an option for a long time. > > I've left some review comments on the PR. > > On Tue, 12 Jan 2021 at 15:29, Paul Ganssle <p...@ganssle.io> wrote: >> >> Yeah, sorry I didn't get around to this until so close to the deadline. >> December was a lot crazier for me than I had hoped. ☹ >> >> One thing I'll note is that this PR to allow using zoneinfo timezones is >> mostly just adding tests. The substantive changes to the codebase are very >> light, and there should be no behavioral change for users of pytz or current >> users of other time zone providers (assuming such people exist). There >> appears to be a nominal attempt to support non-pytz zones in >> django.utils.timezones, so possibly this PR just improves support that was >> already intended to be present in the first place. >> >> I do think it would be good to make it possible for people to do some >> conversion over ahead of time if possible, particularly since no deprecation >> warnings will be issued prior to the change away from pytz. >> >> Best, >> Paul >> >> On 1/12/21 10:12 AM, Carlton Gibson wrote: >> >> Hi all. >> >> Paul Ganssle has followed up his earlier PoC PR, and the previous >> discussion, with a smaller PR in order to allow using zoneinfo timezones >> without an error: >> >> Add support for non-pytz zones >> https://github.com/django/django/pull/13877 >> >> The idea is to target 3.2 for this. (Recall for 4.0 we'll switch to >> zoneinfo, allowing folks to opt-in to the pytz compatibility shim, if >> needed.) >> >> First glance, it looks OK, great even (absolutely as expected from Paul). >> >> I don't have capacity to properly sit down with it before the feature freeze >> (due Thursday) though. >> So if it were just me, I'd have to say it's too hot, too close to the >> deadline, and we should just target 4.0 >> >> However, maybe others, and the Technical Board who have the authority to >> specify, think that this is something we should take the extra time if >> needed and make sure we get in for 3.2? >> (Any extra eyes reviewing would help in that case.) >> >> As per Aymeric's point on the previous discussion, it's likely this doesn't >> affect most of our users. >> Paul's concern is that Django incompatibility (along with Pandas he >> mentioned in discussion) is blocking adoption throughout the community. >> That's not necessarily our problem, but maybe this is a small enough change >> that we should be flexible here? >> With 3.2 being the next LTS, it'll be around for a while (which is relevant >> I think). >> >> Can I ask for opinions please? Again, the option is to say that we'll >> squeeze this in if review is fine. >> The feature freeze isn't cast in stone, but we do have to draw the line >> somewhere. >> This one is sufficiently interesting that Mariusz and I don't want to just >> decide with consultation. >> >> Thanks. >> >> Kind Regards, >> >> Carlton >> >> >> >> >> On Monday, 4 January 2021 at 10:56:42 UTC+1 Carlton Gibson wrote: >>> >>> Hi all, >>> >>> Happy New Year! >>> >>> Time to begin release process for the next major release, Django 3.2! >>> >>> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap >>> >>> The 3.2 feature freeze is scheduled for January 14. >>> We'll probably release the alpha that day. >>> >>> We have a few larger patches we want to finish reviewing: >>> >>> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added support >>> for functional indexes. >>> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support >>> rotation of secret keys. >>> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted >>> admin colors into CSS variables. >>> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed #29138 -- >>> Added limit_choices_to and to_field support to autocomplete fields. >>> >>> We'll update this thread for any schedule changes. -- Paolo Melchiorre https://www.paulox.net -- 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/CAKFO%2Bx7sbbZCeJmPGmaf%2BfS8ASCYm-WVxS37nKZAEKFsJ%2BgxXA%40mail.gmail.com.
