Proposal: Drop dependency on pytz in favor of zoneinfo

[Paul Ganssle]

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-standard interface is a major source of bugs
. In
fact, the creator and maintainer of pytz said during the PEP discussions
that he was looking forward to deprecating pytz
.
After merging zoneinfo upstream into CPython, I turned the reference
implementation into a backport to Python 3.6+
, which I continue to maintain
alongside the upstream zoneinfo module, so it is already possible to
migrate Django /today/.

Right now, Django continues to use pytz as its source of time zones,
even for simple zones like UTC; I would like to propose starting the
migration to zoneinfo /now/, to enable Django users to start doing their
own migrations, and so there can be ample time for proper deprecation
cycles. I apologize in advance for the huge wall of text, the TL;DR
summary is:

  * It's important to start this migration as soon as possible, because
it will take a long time and some of the bugs it fixes get worse as
time goes on; right now Django's assumption that all time zones are
from pytz will likely block Django users from migrating before
Django does.
  * The combination of pytz's non-standard interface and Hyrum's Law
 makes this less straightforward than
one would hope. Likely the best solution is to adopt "zoneinfo"
immediately with a wrapper that deprecates the pytz-specific
interface. I have provided a library to do this
.
  * There are some open questions (which may only be open because I
don't know Django's process well enough) in the migration plan:
  o Should this change be put under a feature flag of some sort? If
so, what should be the default values for coming releases?
  o Should /all/ the pytz-specific tests be kept with zoneinfo tests
added, or should they be migrated and pytz tests confined to a
smaller subset?

*Rationale*

Before I get into the detailed migration plan, I'd like to lay out the
case for /why/ this needs to be done. I expect it to be at least
somewhat painful, but and I'd prefer it if y'all were convinced that
it's the right thing to do /before/ you hear about the costs 😉. I am
not the kind of person who thinks that just because something is in the
standard library it is automatically "better" than what's available on
PyPI, but in the case of pytz, I've been recommending people move away
from it from a long time, because most people don't know how to use it
correctly. The issue is that pytz was originally designed to work around
issues with ambiguous and imaginary times that were fixed by PEP 495 in
Python 3.6, and the compromise it made for correctness is that it is not
really compatible with the standard tzinfo interface. That's why you
aren't supposed to directly attach a timezone with the tzinfo argument,
and why datetime arithmetic requires normalization. Any substantial code
base I've ever seen that uses pytz either has bugs related to this or
had a bunch of bugs related to this until someone noticed the problem
and did some sort of large-scale change to fix all the bugs, then
imposed some sort of linting rules.

In addition to the "pytz is hard to use" problems (which, honestly,
should probably be enough), pytz also has a few additional issues that
the maintainer has said will not be fixed (unless pytz becomes a thin
wrapper around zoneinfo, which is at best just using a slower version of
zoneinfo). The biggest issue, which is going to become increasingly
relevant in the coming years, is that it only supports the Version 1
spec in TZif files, which (among other issues), does not support
datetimes after 2038 (or before 1902) — this was deprecated 15 years
ago, and it is unlikely that you will find modern TZif files that don't
have Version 2+ data. Pytz also does not support sub-minute offsets,
which is mostly relevant only in historical time zones. And, of course,
pytz is not compatible with PEP 495 and in some ways really cannot be
made compatible with PEP 495 (at least not easily).

Of course, one reasonable objection here is that Django is a huge
install base with very long release cycles, and it doesn't make sense
for Django to be an experimental "early adopter" of the new library.
This is a reasonable response, but it's actually /because/ it has a huge
install base and long release cycles that it's important for Django to
migrate early, because it can't "turn on a dime" like that. The long
release cycles mean that changes 

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

[Paul Ganssle]

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

I'm hesitant to say that it's a good idea to jump directly to using
zoneinfo with /no warning/, though. I see two possible ways to get a
reasonable warning here:

1. Configure localize and normalize separately, such that localize works
as expected, but normalize raises an exception (possibly we can go more
granular with this so that, for example, UTC.normalize is just a
warning). This could even be achieved with separate warning classes for
localize and normalize, with the normalize warning configured as an
error by default.

2. Add a feature flag that allows switching directly to zoneinfo that
will eventually default to True, and replace pytz with a shim /around
pytz/ that raises warnings whenever you use something pytz-specific.
That will give people time to opt in to using zoneinfo with, hopefully,
zero changes in the intermediate. (Unfortunately, though, it doesn't
allow for any incremental migration like pytz_deprecation_shim does).

I do think a simple shim similar to pytz_deprecation_shim would be
appropriate for the UTC object exposed in Django, though. That could be
done immediately with no impact on semantics /and/ allow for incremental
migration, since even pytz's UTC object can be directly attached to
datetimes.

Right now, I think the obvious first step is to add /support/ for
deliberately using zoneinfo / datetime.timezone. This can be done in a
perfectly backwards compatible way, so there's no point in delaying.

Best,
Paul

On 6/20/20 3:34 AM, Kevin Henry wrote:

> 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 it's a good idea to use the shim, though.
> Briefly: 1) The shim is not backward compatible with pytz; 2) To avoid
> the subtle bugs resulting from that, the developer must review pretty
> much the whole scope of their datetime usage when they adopt the shim;
> therefore 3) it will probably be easier on everyone (both developers
> and Django itself) to simply switch directly to zoneinfo.
>
> 1) I'm referring to the change in semantics around datetime arithmetic
> (see here
> 
> for the description in the shim documentation, and here
>  for a simple demonstration).
> Basically, if you're saying anything like "give me the datetime one
> day after this one", the value (both the wall-clock time and the
> actual point-in-time) could change once you stop using pytz.
>
> 2) Because of the above, the developer can't simply drop in the shim
> as a replacement for pytz. They need to review their codebase to see
> if they're doing datetime arithmetic anywhere. If they are, and if the
> change could affect the resulting values, they need to think about
> whether they want to use the old value or the new value. If they want
> the old value, they need to add some more code to recreate it. If they
> want the new value, they need to think about how to reconcile that
> change with previous behavior (and previous values stored in the
> database).
>
> 3) That's the hardest part of the transition, I think, so I'm not sure
> it's actually helpful to delay the rest. Removing calls to localize()
> and normalize() is comparatively simple. The difference between is_dst
> and fold does require some thought, but it's pretty much the same
> thought you need to do arithmetic right, and developers will benefit
> from making those changes at the same time.
>
> In essence, the shim creates another, third way of handling datetimes,
> neither backwards compatible with pytz (due to the change in
> semantics) nor forward compatible with zoneinfo (due to the use of
> normalize(), etc.). And developers might end up in this twilight zone
> for years given typical Django deprecation cycles.
>
> So my thought is simply to not use the shim; developers should either
> be doing things the pytz way or the Python (zoneinfo) way. I don't
> have strong feelings about how that should happen (e.g. a feature
> flag), or when it should happen.
>
> Cheers,
> Kevin
>
> -- 
> 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

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

[Paul Ganssle]

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
> , 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
> .
>
> 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
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ce04a6b7-4409-4b20-ba30-4cd64dc0cabfn%40googlegroups.com
> .

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

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

[Paul Ganssle]

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 already work the same as `zoneinfo` zones, but they
also expose the pytz interface (with the one semantic difference) and
start raising deprecation warnings. Once your code works with the shims
/without/ throwing deprecation warnings, it will also automatically work
with zoneinfo zones.

In the hopefully conservative time scale I'm envisioning, there would be
a feature flag for 3.2 and 4.x where you can opt in to having Django use
`zoneinfo`, so you don't even need to do anything to get rid of the
shims if you don't want to be passing around shim objects (if you have a
mix of shim and non-shim time zones, datetime comparisons and arithmetic
will have slightly different semantics).

Another thing to note: if you want /any/ kind of warning, you need some
kind of shim, because there are many ways to use pytz time zones that
are not a problem. You need to target the deprecation warnings for code
that actually uses pytz's API, which means wrapping pytz's API. Without
actually supporting zoneinfo, though, users can't actually /do/ anything
with the warning, so they would be forced to change all their time zone
logic at the same time as updating their Django version. My
pytz-deprecation-shim module exposes time zones that don't raise any
warnings if you use them like zoneinfo objects, so people have the
option to gradually move their code into a state where flipping the
switch from pytz to zoneinfo would have very little effect.

Of course, this is all very conservative and assumes that the ability to
gradually migrate is broadly desirable. It may be that Django users by
and large prefer doing major overhauls all at once rather than a
protracted period of gradually upgrading. It also may be that the shims
have some disadvantages I haven't found yet that makes them much worse
than a sudden break. It may also be that y'all would prefer a little
extra pain now to supporting the shim chimera for the lifetime of the
4.x branch.

In my opinion, the strongest argument in favor of a sudden breaking
change in 4.0 would be that the sudden change will be much louder
because stuff will just /break/. With the shims, you'll get a bunch of
Deprecation Warnings (which many people may not see because they are off
by default), and the one backwards-incompatible change is a fairly
subtle difference in arithmetic that only applies in certain situations.
It would be a lot easier to not notice the change until you see a bug
caused by it showing up in production. On the other hand, people not
testing for this adequately may not realize that the semantics are
different than most people think, so they  might have the same bug anyway.

Best,

Paul

On 10/7/20 11:52 AM, Nick Pope wrote:
> 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 changing
> to zoneinfo in 5.0
>  2. Just make a hard break to zoneinfo in 4.0 replacing
> the pytz dependency with backports.zoneinfo;python_version<"3.9"
>
> If I'm honest, I actually prefer the second option for the following
> reasons:
>
>   * It avoids having to go through the rigmarole of updating this
> stuff twice. One release with big shouty warnings is better than two.
>   * People jumping from 3.2 LTS to 4.2 LTS to 5.2 LTS will still have
> two "consecutive" releases fiddling with this.
>   * When Django 5.0 is released in January 2024, we'll still need to
> use the backport as Python 3.8 isn't retired until October 2024.
>   * We don't need to introduce, maintain, deprecate, and remove any
> extra settings for choosing the pytz vs zoneinfo.
>   * As Paul mentioned, most people are probably not using pytz's
> .normalize() properly anyway...
>
> The disadvantage is that users have to make a major change. But
> they're going to have to sooner or later anyway.
> Using the shim doesn't stop them from having to rewrite their 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 becoming
> much easier!
>
> Kind regards,
>
> Nick
>
> On Wednesday, 7 O

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

[Paul Ganssle]

ery hard to square that with Django's stability
> policy: "We’ll only break backwards compatibility of these APIs
> without a deprecation process if a bug or security hole makes it
> completely unavoidable."
>
> If we're going to follow the deprecation process, then there needs to
> be some overlap where both ways of doing things are possible. The
> shims package is a promising approach, but the fact that it's not
> actually backwards compatible with pytz is a serious problem. Adopting
> it directly as Carlton proposes also seems to violate the stability
> policy, albeit in a less severe way.
>
>
> Kevin
>
> On Thursday, October 8, 2020 at 11:35:21 PM UTC-7 smi...@gmail.com wrote:
>
> 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 breaking change in 4.0, would that not
> have the same impact on folk upgrading to 4.2LTS from 3.2LTS as
> that which Carlton is concerned about (3.2 from 2.2), albeit a few
> years further into the future. 
>
>
> David
>
> On Thursday, 8 October 2020 at 09:08:50 UTC+1 jure.er...@gmail.com
> wrote:
>
> 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 currently
> favoured, but not yet default than on a deprecated one, even
> if it's not yet officially deprecated. We do have some "import
> pytz", but currently they are few. Once we have a proper
> approach to handling timezone stuff, there's likely going to
> be more of them... or less, depending on the solution ;-)
>
> LP,
> Jure
>
> On 7. 10. 20 17:25, Paul Ganssle wrote:
>>
>> 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 thi

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

[Paul Ganssle]

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 the same information that it has?
>
No for two reasions:

1. The shims wrap zoneinfo (and dateutil, though that is not relevant in
this case), they do /not/ wrap pytz (and in fact do not have a
dependency on pytz, though there is some magic that allows them to play
nicely with things namespaced in pytz).
2. pytz's mechanism for attaching time zones is incompatible with PEP
495. It would not really be possible to have the shims work both as pytz
zones and as PEP 495 zones in all cases.

You are right that it would be possible to make it so that
`shim_zone.localize()` basically does what pytz does, attaching a tzinfo
specific to the offset that applies at that time, and for
shim_zone.normalize() to make sure that the one attached is the right
one, while also allowing `tzinfo=shim_zone` to work as a PEP 495 zone.
That would make it very difficult to reason about the system, though. It
would make it so that depending on how you attached your time zone, you
would get different semantics for comparisons and arithmetic. Sometimes
normalize would work and sometimes it wouldn't. So, for example, imagine
you have:

def f(dt):
    return shim_zone.localize(dt)

x = shim_zone.normalize(f(datetime(2020, 10, 31, 12) + timedelta(days=1))


If someone changes `f` to instead use `dt.replace(tzinfo=shim_zone)`,
the value for `x` changes, because some function you have is no longer
using `localize`. Similarly, if we have say `datetime.now(shim_zone)`
return a non-localized datetime, you have differences in semantics
between `shim_zone.localize(datetime.now())` and
`datetime.now(shim_zone)` (both of which are valid with pytz). If we
have it return a /localized/ datetime, subtraction and comparison
semantics would be affected, because now times localized to one or the
other offset will be inter- rather than intra-zone comparisons.

Unfortunately there's simply no way to make it fully backwards and
forwards compatible. The best options I see are a shim around pytz in
3.2 that just adds warnings and doesn't do anything else, followed by a
hard break in 4.0 or pytz-deprecation-shim in 4.0 and hard break in 5.0.

I think both are fine plans. I suspect that the slower plan will get
people upgrading to 4.0 much faster, but it does have the disadvantage
that some of the breakage is subtle and won't raise big errors (which is
also the case, though to a lesser extent, with the faster plan).

In any case, it seems uncontroversial that 3.2 should support "bring
your own zoneinfo", and I think most people agree that a feature flag in
3.2 is also a good idea, so to the extent that I have time to work on
this, I'll work on those things.


Best,
Paul


> So, for example, you could wrap pytz and keep a shadow copy of the
> pytz tzobject inside your tzobject, and use that to determine the
> correct behavior whenever a pytz-specific call is made. So when
> localize() is called you call localize on your internal object, and
> store that pytz EST tzobject. Then when normalize() is called you use
> that to get pytz's version of the EDT time.
>
>
> > This occurs because localized pytz zones are different tzinfo
> objects, and as such comparisons and subtraction use inter-zone semantics.
>
> Thank you for that example, I hadn't considered that. Unfortunately
> that is another fundamental incompatibility between pytz and any
> shim-around-zoneinfo (here
> <https://repl.it/@severian/pytzshim-subtract> is a runnable version).
> I can't think of any way around that one.
>
>
> > Of course, there is another option, which is to, rather than
> adopting a wrapper around zoneinfo, adopt a wrapper around pytz that
> does not follow PEP 495, but instead just deprecates `pytz`'s API and
> tells people to turn on the "use zoneinfo" feature flag.
>
> Agreed, that is the other main option. It has a few advantages:
>
> - It's backwards-compatible.
> - Because it's backwards compatible it could be adopted in 3.2,
> allowing a complete transition to zoneinfo by 4.2, a full two years
> earlier than the shims approach.
> - It only requires users to think about the change once, when they opt
> in to the new approach. Using the shim means you have to think about
> this issue at least twice: once when the shim is dropped in and you
> have to figure out if you're affected by the backwards
> incompatibilities; and once (or more) when you actually make the
> change (or a series of changes) over to the native zoneinfo style.
>
> The 

Re: Status of 3.2 release blockers.

[Paul Ganssle]

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
> <https://groups.google.com/g/django-developers/c/PtIyadoC-fI>, 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. 
>
> 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/cc28eb1d-3f24-4103-8a57-6835e775b11an%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cc28eb1d-3f24-4103-8a57-6835e775b11an%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/7e22fc29-d4eb-1141-e389-56d2ace9a0af%40ganssle.io.

Re: Status of 3.2 release blockers.

[Paul Ganssle]

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

-- 
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/CA%2B6apDqXe19BZhoCLQz8Jc-qYrNphYxZuLzKDf7mP4Py%2BNv53A%40mail.gmail.com.