datetime.utcnow and datetime.utcfromtimestamp will be deprecated in 3.12:

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. πŸ“…πŸ•

Β· Β· 8 Β· 38 Β· 34

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:

Show thread

@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 Doing a quick grep of my projects, including venv directories, for 'datetime.utcnow' comes back with results from protobuf, black, blackd and pydantic.

One of pip's depedencies, cachecontrol, also comes up.


@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.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.