Proposal: Drop dependency on pytz in favor of zoneinfo

Greetings all, Now that PEP 495 (the fold attribute, added in Python 3.6) and PEP 615 (the zoneinfo module, added in Python 3.9) have been accepted, there's not much reason to continue using pytz, and its non-s

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I'm almost exclusively a lurker on this list, but a constant user, and have in the past a keen observer in the datetime discussions. I think you've made your case well. I'd be happy for this migration from Django to be as aggressive as the maintainers are comfortable. I agree that doing step 1 at

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Thanks to Paul for this proposal, and for working to put proper timezone usage into Python itself. PEP 495 and 615 definitely make Python better, and it seems inevitable that everyone will sooner or later switch over. I'm all for getting this process going in Django. I have doubts over whether

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

The point about the arithmetic semantics is a good one. I'm curious to know how often this is actually a problem. I think it will happen strictly less frequently than the localize case, which /is/ handled in both a backwards and forward-compatible way, and I hate to throw the baby out with the bath

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

> The point about the arithmetic semantics is a good one. I'm curious to > know how often this is actually a problem. > That’s an interesting question. I think that doing localized datetime arithmetic in Django is idiomatic, if not necessarily common. Let’s say we have a calendar application t

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Hi Carlton, Thanks for coming back to this. Your reasoning makes a lot of sense. I too think it'll be good not to land this in 3.2 LTS and focus on making any changes in 4.0. The question is then which path we choose to take: 1. The deprecation route using pytz_deprecation_shim in 4.0 chang

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I think either jumping straight to zoneinfo in 5.0 or using the shim in 4.0 would be fine, though I will say that it is very likely that if you don't want to change your code twice you won't have to, particularly if we add a feature flag to opt-in to zoneinfo even in 3.2. The shim time zones alrea

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I would definitely be in favor of an opt-in: it would give developers time to move to the new system at their convenience. Example: we're about to try and tackle the TZ issue in our apps and we want to do it "globally" with one definitive solution. I'd much rather do it on a library that is cu

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Hi All, While I understand the desire to have an early opt-in for some I think the important question here is the deprecation warnings. The recent URL() change showed that no matter how long there is a new way some?/many? folk won't change until they need to. Nick -- if we introduced a breaki

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I think that the simplest approach—the one that would result in the least amount of total work for both Django and its users—would be to adopt Nick's suggestion and just switch to zoneinfo in 4.0. The problem is that it's very hard to square that with Django's stability policy: "We’ll only break

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

The reason I suggested going with Paul's shim is that it allows folks to update without having to stop there and then to make code changes. Yes, they'll need to review the deprecation warnings, and there's the issue with datetimes over offset changes, but we can call that out in the release not

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

> Before looking at alternatives, I wonder if we can just change the > shims package to make it fully backwards compatible? Right now the > shims version of normalize() >

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

> > The deprecation route using pytz_deprecation_shim in 4.0 changing to > zoneinfo in 5.0 I'm in favour of this plan, with the feature flag to use zoneinfo. As Carlton wrote, a hard change that requires modification of code will stop users from upgrading, and that's not great. Another option is

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

> It is not really possible to make the shims work the same way because there's not enough information available to determine whether an adjustment needs to be made. But since you're shimming pytz, don't you, by definition, have access to the all the same information that it has? So, for examp

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

On 10/9/20 2:46 PM, Kevin Henry wrote: > > It is not really possible to make the shims work the same way > because there's not enough information available to determine whether > an adjustment needs to be made. > > But since you're shimming pytz, don't you, by definition, have access > to the all

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Sorry guys for asking a really stupid question, but : I just made a search for pytz in Django master and found 17 occurrences in 5 files. More in docs and tests though. But still. Isn't what we're debating here moot since Django itself doesn't really depend on pytz all that heavily? I mean, I

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

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 fallin

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Hey Nick, Super, no problem. 4.0 is fine. (And Aymeric's option does sound better yes.) Thanks! C On Wednesday, 6 January 2021 at 16:12:32 UTC+1 Nick Pope wrote: > 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 stag

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I'm also +1 on Aymeric's suggestion. On Wed, 6 Jan 2021 at 15:44, Carlton Gibson wrote: > Hey Nick, > > Super, no problem. 4.0 is fine. (And Aymeric's option does sound better > yes.) > > Thanks! > C > > On Wednesday, 6 January 2021 at 16:12:32 UTC+1 Nick Pope wrote: > >> Hi Carlton, >> >> Sorry