Python 3.13 deprecation of utcnow()

[jenstroeger]

Hello,

I’m seeing several deprecation warnings like

/path/to/.venv/lib/python3.13/site-packages/webob/cookies.py:238: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  v = datetime.utcnow() + v

and other utcnow() related calls. Are there any plans to address this issue soon? Happy to provide a PR.

[mmerickel]

I have no concerns about any internal fixes - but I'm worried about areas where it'll hit the public api surface.

[jenstroeger]

Right… by moving from naive utcnow() to aware now(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

webob/src/webob/cookies.py

Lines 241 to 242 in 39d5af3

	if isinstance(v, timedelta):
	v = datetime.utcnow() + v

to

 if 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?

[mmerickel]

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() with datetime.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?

[mmerickel]

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.

[jenstroeger]

[…] 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:

1. Just address the utcnow() deprecation warnings and maintain the external interface (see above); or
2. Create a breaking change and migrate the package to aware and aware only datetimes.

[mmerickel]

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.

[mmerickel]

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.

[jenstroeger]

How about we start with a PR that replaces all deprecated naive utcnow() calls with aware now(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.

[mmerickel]

Yeah that sounds the most comfortable to me.

[jenstroeger]

@mmerickel will you be able to merge and release this soon?

[jvanasco]

Right… by moving from naive utcnow() to aware now(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.