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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c3a3a788-2300-4361-ab06-0d89523424ecn%40googlegroups.com.
