Why is datetime.datetime.utcnow() deprecated, and what replaces it?

### What `utcnow()` actually returned `datetime.datetime.utcnow()` read the system clock, converted it to UTC, and then returned a **naive** `datetime` — the correct UTC wall-clock fields with `tzinfo` left as `None`. The value was right and the label was missing, which is the worst combination: it looks like a UTC timestamp, prints like a UTC timestamp, and is indistinguishable at runtime from a local-time reading produced by `datetime.datetime.now()`. Everything downstream then has to guess, and the standard library guesses *local*, not UTC: * `astimezone(...)` on the result treats the fields as local time and shifts them, so on a machine whose clock is not UTC the instant silently moves. * `timestamp()` on the result likewise interprets the fields as local time, producing an epoch value wrong by the machine's offset. * Comparing it against a properly aware value raises `TypeError` for ordering, or quietly answers `False` for equality. * Serialising it drops the offset from the output, so consumers cannot recover the intent. The bugs that follow are the classic ones: timestamps off by whole hours, records that sort into the wrong order around a deployment that changed the container's zone, and code that behaves correctly on a CI runner set to UTC and wrongly on a developer laptop. ### The deprecation **Python 3.12** deprecated both `datetime.datetime.utcnow()` and `datetime.datetime.utcfromtimestamp()`. Calling either emits a `DeprecationWarning`. The functions still exist in 3.14 — this is a deprecation, not a removal — but they are on the way out and should not appear in new code. Remember that `DeprecationWarning` is hidden by default outside `__main__`, so a large codebase can call `utcnow()` thousands of times and show nothing. Surface it deliberately: run the test suite with warnings promoted to errors for that category, or configure the warnings filter in the test harness so a new call fails the build. ### The replacements | deprecated | replacement | |---|---| | `datetime.datetime.utcnow()` | `datetime.datetime.now(datetime.timezone.utc)` | | `datetime.datetime.utcfromtimestamp(ts)` | `datetime.datetime.fromtimestamp(ts, datetime.timezone.utc)` | Both replacements return **aware** objects whose `utcoffset()` is a zero `timedelta`. Since Python 3.11 `datetime.timezone.utc` also answers to the shorter alias `datetime.UTC`, so `datetime.datetime.now(datetime.UTC)` is the same call written more briefly. ### The migration is not a blind find-and-replace The two calls do not produce identical objects: the old one is naive and the new one is aware, and that difference propagates. A codebase that swaps `utcnow()` for `now(datetime.timezone.utc)` in one place and leaves naive values elsewhere has just created the mixed comparisons described above — the sort that raises `TypeError`, or worse, the equality that answers `False` and hides. So the change is a boundary migration, not a token substitution: 1. Convert the clock reads first, since those are the source of new values. 2. Tag the values arriving from storage and parsing at the same boundary, deciding explicitly what the stored naive values meant. 3. Look for the places that compare, sort, subtract or key on a timestamp, and confirm both sides are now aware. 4. Add a guard at the edge that rejects a naive value outright rather than defaulting it. ### Why the interviewer asks It separates a candidate who repeats "use `now(datetime.timezone.utc)`" from one who can say *why* the old call was wrong: not that it returned the wrong time, but that it returned an untagged time, and that Python's default interpretation of an untagged time is local, not UTC. The second answer also explains why the migration is riskier than it looks, and why the fix belongs at the process boundary rather than at each call site. ### What did not change `datetime.datetime.now()` with no argument still returns a naive local reading and is **not** deprecated — it is a legitimate call when you genuinely want a local wall-clock value for display. `datetime.datetime.now(tz)` with any `tzinfo` returns an aware value. And `datetime.datetime.utcnow()` remains importable and callable in 3.14; nothing breaks today, which is exactly why the warning has to be surfaced deliberately before a future removal turns a warning into an `AttributeError`. ### A quick self-check for any timestamp helper If a utility in your codebase returns "now", ask two questions of it: does the returned object's `utcoffset()` come back as something other than `None`, and does every caller keep it that way? A helper that returns an aware value which a caller then strips with `replace(tzinfo=None)` — usually to satisfy a storage layer or a serializer that rejects offsets — has reintroduced exactly the condition the deprecation was meant to end, one layer further down. The fix is the same as the original one: keep the offset all the way to the boundary, and if a component genuinely cannot store it, record UTC by convention, name the field so it says so, and tag the value again the moment it is read back.