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

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

re) when you actually make the > change (or a series of changes) over to the native zoneinfo style. > > The main disadvantage—and a real one—is that it's more work for Django. > > > Cheers, > Kevin > On Friday, October 9, 2020 at 8:06:49 AM UTC-7 Paul Ganssle wrote: &

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

nd 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 currently > favoured, but not yet default than on a deprecated one, even > if it's not yet offici

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

r code a > second time to switch over to zoneinfo. > With good documentation and examples on how to migrate, I think it > would be a better approach. > > On a final note, I'd like to say thank you to Paul for fixing this > major timezone handling wart. I'm looking forward to life becomin

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

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

Re: Status of 3.2 release blockers.

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

Re: Status of 3.2 release blockers.

PM Adam Johnson 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