I’d like to emphasize the impact of removing utcnow in one specific project because I believe that, in this thread, the amount of developer time required for this transition was somewhat underestimated. However, if my perception is inaccurate, I stand corrected.
When I mention “churn” I’ll be referring to the process of getting a (PR) merged that removes utcnow and all the resulting consequences. This will therefore cover beyond the direct impact of utcnow, because in my opinion this is the boarder impact deprecations have.
Pip
You initially raised this issue to identify a few places where utcnow was being used, both within Pip’s own codebase and in a vendored package, cachecontrol. Looking at these two:
1. Pip’s Main Codebase
Two PRs were opened, this one attempted a direct substitution from datetime.datetime.utcnow() to datetime.datetime.now(datetime.timezone(datetime.timedelta(0))).
However, that PR was abandoned in favor of this one which not only replaced utcnow but also took the opportunity to substitute some date format parsing logic with the fromisoformat method. This led to user issues, including problems building wheels and users encountering errors during checks.
2. Updating Cachecontrol
You opened this PR to remove utcnow in the cachecontrol project. I’m not aware of any specific issues it caused but I would point out that the logic involved was more complex and required suppressing type hinting for one line.
The key aspect here is that this PR probably only got merged because the project ownership changed hands. When you initially submitted the PR, the project was unmaintained. This situation extended beyond just utcnow, leading to the project being initially forked but later taken over and moved into the PSF GitHub organization.
Opinionated conclusions
Based on “1.” I recommend developers who want to ensure safety in their PRs should opt for a straightforward replacement of datetime.datetime.utcnow() with datetime.datetime.now(datetime.UTC).replace(tzinfo=None) (I’ve already implemented this in my company’s codebase). As observed, simple changes in complex applications with many users can easily result in issues.
Furthermore, when the deprecation turns into a removal, my plan is to create a tool to audit our entire dependency tree (currently ~300 modules) for any use of utcnow. If we find anything, we will either raise issues, fork, or vendor and patch it. Hopefully, less experienced users will be spared from these issues by the time of the release.
I guess if you really think that utcnow has no valid use case then all of this is reasonable, but I continue to model my excel and database timezoneless datetime data types in Python, and mostly utc is implied.