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 > <https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html#handling-datetime-arithmetic-normalizing-datetimes> > for the description in the shim documentation, and here > <https://repl.it/@severian/pytzshim> 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c3a3a788-2300-4361-ab06-0d89523424ecn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c3a3a788-2300-4361-ab06-0d89523424ecn%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/642fba14-44cf-6114-f0eb-06f445c6d95a%40ganssle.io.
signature.asc
Description: OpenPGP digital signature
