The reason I suggested going with Paul's shim is that it allows folks to update without having to stop there and then to make code changes. Yes, they'll need to review the deprecation warnings, and there's the issue with datetimes over offset changes, but we can call that out in the release notes, and doing it *after *the LTS allows people to hold off. I have sympathy for Nick's suggestion but think it'll result in people not updating, which is something in recent years we've managed to avoid.
As Paul points out, users will only have to update their code once. That we do all we can to avoid hard breakages is one of Django's biggest pluses. For me, for us to need to remove the shim at 5.0 is a cost that's worth paying. (It's not a big burden.) Happy to see a PoC on an alternative but, I think additional complexity to create a shim that's 100% seamless, or to have an opt-in setting where we branch code for an extended time, will not be worth the price of admission. It's unfortunate that there's a breaking change here but, as long noted on the pytz docs <http://pytz.sourceforge.net/#introduction> it's inevitable. -- 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/e48706f2-b2e9-40e3-95d9-9d22a2a0598en%40googlegroups.com.
