A while back, Python core contributor Paul Ganssle opened a proof-of-concept PR on Django to deprecate use of
pytz and move to use of the new
zoneinfo module, that was introduced in Python 3.9, with a backport available all the way to Python 3.6.
I got round to taking this on this week. We’re a way from the Django 3.2 feature freeze, but I’m old now, and I like a bit of hustle early in the cycle, rather than right to the wire.
The proposal is to move to using
zoneinfo and introduce a shim that is more-or-less backwards compatible with
pytz, but which raises a warning when
pytz specific methods (
normalize()) are used.
The issue is this would be a breaking change. Even with the shim there’s a semantic difference in how
datetime arithmetic is handled over UTC offset changes. Some links:
The bottom-line is that if you're doing
datetime arithmetic, and calling
normalize() afterwards (which you should be, in case you crossed a DST-change boundary) then you’re going to need to review and update this code if we move to
I advise you to have a read of the discussion on the django-developers list, and think about these issues. Presumably you’re using
pytz. You’re going to need to move away over the next few years. (Paul’s article on the issues with
pytz is worth reviewing here.) In your own code, you likely just want to sit down and update, but for a library, and library like Django in particular, where we do all we can to not break your code, the use of
pytz-deprecation-shim seems a small cost to pay to help users upgrade.
The currently proposed timeline for all this is:
zoneinfobehind a feature flag, for those wishing to opt-in early.
pytz-deprecation-shim, so that warnings will be raised for the old usage in user code. Doing this after the next LTS allows users to hold-back for a while if they need more time. It also allows folks to upgrade from Django 2.2 without having something else to worry about.
pytz-deprecation-shim. Transition complete.
This isn’t seamless. There’s still the breaking change in the semantics, and users will be best served to deal with that early. I’m not sure I can see a better way, though:
I opened a PR on DEP 10 (Django’s governance) to add a Triage & Review Team role.
Theoretically there’s no need for this to be part of DEP 10, except that it covers when a Merger (and by this I really mean Mariusz) may merge their own minor changes.
Rightly, such things need approval, but I’d often arrive on a Tuesday morning to find Mariusz has made a small tweak, approved by multiple regular contributors, but not merged because it needed another Merger’s approval (mine or Claude’s).
What pushed me to action was the result of the recent Technical Board election, in which Simon Charette, who’s the main active contributor to the ORM (for a long-time), did not get re-elected. That’s fine: the new board are all great. But Simon and Mariusz often work closely on quite arcane issues, and Simon approving Mariusz’ changes is an important workflow. (TB members can already approve Merger PRs under DEP 10.)
The first of these cases is just a bit silly, the second, that Simon’s approval is not sufficient, is kind of ludicrous. Hence, the proposed change. It’s fine that DEP 10 needs adjustment as it’s implemented. That’s to be expected… (something about the best laid plans and meeting the enemy…)
I set up Pi-hole on my home network this week. Oh my, it’s good!
I’ve long run ad-blockers on device. Don’t we all. But these don’t always work in-app. In particular, I use The Economist app, but they insert adverts into the articles. Often these are for related materials, but I finally lost the plot when they started showing smartphone adverts. (The Economist is subscription-based, and whilst I think it’s good value, it’s not cheap.)
Network-wide Ad Blocking — A black hole for Internet advertisements
I had a Raspberry Pi sat there not doing anything. Connected by Ethernet to my router and installed Pi-hole. Whole thing took less than an hour, including a bit of head scratching working out to renew DHCP leases so devices would use the Pi-hole for DNS. (This last would happen eventually but…)
Tl;dr: I can’t recommend it enough.