`datetime.utcnow` and `datetime.utcfromtimestamp` will be deprecated in #python 3.12: https://github.com/python/cpython/issues/103857
If you maintain a package, now is probably a good time to grep your source code for `utcnow` and `utcfromtimestamp` to get out ahead of the deprecation warnings. 📅🕐
@pganssle Ooooh, I applaud this. `now(timezone.utc)` does what I always *think* `utcnow` is gonna do, so I’m all for getting rid of the confusion.l
@pganssle great work, attractive nuisances indeed!
@pganssle Thankfully, I don't see explicit references to either in the code that I've written. Whew!
@pganssle thank you! I get fooled by utcnow() every year or so, glad to see it on the way out!
@pganssle Why not make them do the right thing and include the utc timezone instead of no timezone?
@tewalds That would break backwards compatibility in a much more subtle way, and create a situation where its difficult to tell whether or not you are in compliance. You wouldn't be able to just grep for uses of `utcnow`, and we would have no way of warning you that at some point your code will break.
There's also no easy way to "opt-in" to the new behavior like there is with just not using `utcnow` and `utcfromtimestamp`.
It is better to remove these entirely.
@pganssle I'm getting a deprecation warning from dateutil 😅
https://github.com/dateutil/dateutil/issues/1284
It's relatively easy to make a drop-in replacement for these, but also we're deprecating them because they're conceptually the wrong thing to do, so it's best to migrate to using aware datetimes if possible: https://blog.ganssle.io/articles/2019/11/utcnow.html