Repository navigation
Python 3.13 deprecation of utcnow() #473
Description
Activity
I have no concerns about any internal fixes - but I'm worried about areas where it'll hit the public api surface.
Right… by moving from naive
utcnow()to awarenow(tz=timezone.utc)I ended up moving the whole stack to aware datetimes. Probably a long overdue move anyway.In the case of WebOb I think a transparent change would be e.g. from
Lines 241 to 242 in 39d5af3
toif isinstance(v, timedelta): v = (datetime.now(tz=timezone.utc) + v).replace(tzinfo=None)
This would be a drop-in change to address the deprecation, but could probably be simplified case by case.
Shouldn’t that address your concern about the public API surface?
I guess I'm roping in the reason for the deprecation - not just how to workaround the warning.
The goal of the deprecation is to get people to stop using naive datetimes and/or moving toward assuming that a naive datetime is "local" tz instead of UTC (because this is consistent with the stdlib apis and how they handle naive datetimes).
So sure, if we are just tackling the warning then yeah you can simply replace usages of
datetime.utcnow()withdatetime.now(datetime.UTC).replace(tzinfo=None)and we are done.I was assuming you were also proposing the rest, in which you're actually changing the library to use tz-aware datetime objects which is a much bigger change.
Can you clarify your proposal?
To be clear - changing webob to expect tz-aware datetimes and expose tz-aware datetimes at the public api surface is secondary and much more controversial - we'll need to do that carefully.
[…] we'll need to do that carefully.
Agreed. But mixing aware and naive datetimes also requires care because they can’t be compared. So I think the question becomes:
- Just address the
utcnow()deprecation warnings and maintain the external interface (see above); or - Create a breaking change and migrate the package to aware and aware only datetimes.
- Just address the
Well let’s break it into two separate units of work if it's ok to you. But your choice.
This datetime to tz-aware thing is like the python 3 change to Unicode but even more subtle imo. Personally to consider the second part I need to know more about what APIs are affected. I know cookies come to mind immediately and cache headers but perhaps there are more.
Obviously we can continue to accept naive datetime objects and treat them as we always have (as utc for now??) which may be inconsistent with the stdlib but bw-compat at least.
The biggest issue is where we expose a datetime for a user to consume because it will absolutely break for them if it becomes tz-aware.
How about we start with a PR that replaces all deprecated naive
utcnow()calls with awarenow(timezone.utc)calls and, depending on context, either- strips the aware datetime of its timezone resulting in a naive UTC datetime (just like
utcnow()would deliver); or - continues with the aware datetime if required.
That should be drop-in change and would give us a good idea which places will be affected by the change. We can take this discussion from there.
Reacted by Jonathan Vanasco- strips the aware datetime of its timezone resulting in a naive UTC datetime (just like
Yeah that sounds the most comfortable to me.
@mmerickel will you be able to merge and release this soon?
Reacted by Jonathan Vanasco and Mike FiedlerRight… by moving from naive
utcnow()to awarenow(tz=timezone.utc)I ended up moving the whole stack to aware datetimes. Probably a long overdue move anyway.I just wanted to note this library is fairly stable, so people who don't want to adopt that migration can pin their releases.
I've migrated several projects over the past few months. This is considerably simpler than the unicode transition.
- added a commit that references this issue
on Feb 8, 2026 @mmerickel ping on this issue and PR #475.
- added a commit that references this issue
on May 28, 2026 @mmerickel @luhn @digitalresistor (or whoever maintains this repo) can you please address this issue and one of the PRs #475 or #480 or #488, then ship a new release? Please?
Reacted by Tanguy Rossel- added a commit that references this issue
on Jun 13, 2026 Yup. Working on it.
- added a commit that references this issue
on Aug 3, 2026
Hello,
I’m seeing several deprecation warnings like
and other
utcnow()related calls. Are there any plans to address this issue soon? Happy to provide a PR.