> The point about the arithmetic semantics is a good one. I'm curious to > know how often this is actually a problem. > That’s an interesting question. I think that doing localized datetime arithmetic in Django is idiomatic, if not necessarily common. Let’s say we have a calendar application that allows users to create events and set reminders. A typical way to handle an event creation request would be to activate() the user’s timezone and then read a localized datetime from the Form. Now, to create reminders, you add a timedelta of a day, a month, etc. and then store that result in the database. This datetime could be different under the new semantics.
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). > That is approximately what I was thinking. For the sake of example, I’ll present an opt-in approach modeled after the New Middleware transition (though I haven’t given the opt-in mechanism much thought): - In version X, Django deprecates usage of pytz and introduces the TIMEZONE setting. It has the same meaning as TIME_ZONE, but the use of it signals that the user is opting into zoneinfo. If it’s set, Django does not use or assume pytz. - If it’s not set, Django uses pytz and gives the user deprecation warnings. Those could come from a system check; or when Django datetime utilities are used; or via a shim around timezone objects; or something else. - In version Y, pytz and TIME_ZONE usage is removed. As you say, the main difference from your proposal is that there’s no way to mix pytz and zoneinfo. Trying to allow that would slow down and complicate the transition, and I'm just not seeing much of a benefit to outweigh that. (Just one perspective, of course...) 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/9072bb07-9455-456e-b783-2834a84eab4an%40googlegroups.com.
