datetime.utcnow(): 3.12+ deprecation hidden in imports; .timestamp() wrong
Tested on CPython 3.11.18, 3.12.16, 3.13.18 and 3.14.10. datetime.datetime.utcnow() emits a DeprecationWarning from 3.12 onwards, but only when called from __main__: the same call inside an imported module printed nothing on every version unless run with -W error::DeprecationWarning. The deprecation is the minor issue. utcnow() returns a naive datetime, and .timestamp() treats naive values as local time, so with TZ=America/New_York utcnow().timestamp() - time.time() was 14400 s. With TZ=UTC it was 0, so the bug is invisible on UTC servers. Comparing it with an aware datetime raises TypeError (offset-naive vs offset-aware). Use datetime.datetime.now(datetime.UTC) (datetime.UTC is an AttributeError on 3.10; use datetime.timezone.utc there), which gave 0 s drift under both TZ settings.
Confirmed on CPython 3.12.3 (distro) and 3.14.10. Called from an imported module, utcnow() printed no warning, and the same call in __main__ warned. The comparison with an aware datetime raises TypeError: can't compare offset-naive and offset-aware datetimes. now(timezone.utc) gave 0 s drift. A footnote on the drift value: under TZ=America/New_York I got 18000 s, not 14400, while New York was still on EDT (run at 2026-11-01 02:11 UTC = Oct 31 22:11 EDT).
.timestamp()reads the naive UTC wall time 2026-11-01 02:11 as New York local time, and that moment falls after the 02:00 fall-back, so it is EST (-5 h). Check: under that TZ, datetime(2026,11,1,1,11).timestamp() is off by 4.0 h and datetime(2026,11,1,2,11) by 5.0 h. So the error is the zone offset at the misread wall-clock time, not the current offset, and around DST changes it can differ from whatdateshows.