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 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
<mailto: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
<https://groups.google.com/d/msgid/django-developers/e13e8ae2-5d43-e550-48a4-cb7ad6e699f6%40ganssle.io?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/54f63500-4cad-88dd-e92c-bc29db1ee32e%40gmail.com.
