Fixed #32366 -- Updated datetime module usage to recommended approach.

[carltongibson]

Using .now() is the modern recommended approach.
https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow

More depth here:
https://blog.ganssle.io/articles/2019/11/utcnow.html

Extracted from #13877

[felixxm]

Can we update all cases and tests ?

• django/utils/http.py: current_year = datetime.datetime.utcnow().year
• django/core/cache/backends/db.py: now = datetime.utcnow()
• django/http/response.py: delta = expires - expires.utcnow()

[carltongibson]

Yep, good call. I'll do that later on.

[ngnpope]

Can you also address datetime.utcfromtimestamp() and datetime.utctimetuple() which carry similar admonitions?

[carltongibson]

Ok, super. I'm touching the methods using those now so...

I think I'll add a ticket.

[ngnpope]

Ok, super. I'm touching the methods using those now so...

🏅

I think I'll add a ticket.

Good call.

[pganssle]

Can you also address datetime.utcfromtimestamp() and datetime.utctimetuple() which carry similar admonitions?

I think utctimetuple() is a bit more complicated, but utcfromtimestamp() largely has all the same admonitions yes.

The biggest "legitimate" use case I have for utcnow() is when you are immediately attempting to use isoformat() on a datetime but don't want the offset included, e.g.: dt.utcnow().isoformat() + "Z", because .isoformat() will include +00:00 on an aware datetime in UTC. If we remove utcnow and utcfromtimetuple, then that will turn into dt.now(utc).replace(tzinfo=None).isoformat() + 'Z', which is slower and more awkward, but possibly worth it because these methods are mostly misused.

utcfromtimestamp() usually has one additional "legitimate" use case, which is that occasionally (and I occasionally use this in zoneinfo code), someone gives you a timestamp in "seconds since 1970-01-01T00:00:00 in the local zone". This is not a unix timestamp that would be generated by .timestamp, but IIRC the TZif format uses this to specify when transitions happen in "local time" for various reasons. It turns out that .utcfromtimestamp(that_kind_of_timestamp) will give you the correct datetime in local time, which is very convenient. Of course, utcfromtimestamp is a terrible name for a method that gives you the correct local time from something that is not really a "timestamp" in the sense of "timestamp" used by the .timestamp method...

Anyway, these are fairly rare use cases and any instance of utc(now|timestamp) can be replaced by utc(now|timestamp)(...).replace(tzinfo=None) if you actually want a naïve datetime representing UTC, if it's easier to enforce a ban on any use of .utc(now|timestamp), it will just be a bit slower.

[carltongibson]

Thanks @pganssle. I ran out of brain power for this this afternoon but will look at each of the uses to see what we can update.

[ngnpope]

Superseded by #14374.