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