A duration is not a number. It is two numbers added in different spaces, in a fixed order. The P half — years, months, weeks, days — is added to the wall clock and then re-anchored to a real instant. The T half — hours, minutes, seconds — is added to the elapsed count and never consults the calendar at all.
if (hasDate(dur)) { // 1. wall-clock space
var w1 = addCalendar(getWall(zone, epochMs), dur, overflow);
mid = resolve(zone, w1, dis).epochMs; // disambiguation fires HERE
}
var out = mid + timeMs(dur); // 2. exact-elapsed space
Two statements with a resolution between them; fuse them and you have a different engine. This one is a real Temporal/RFC 5545 resolver with zero embedded tzdata — every fact about a zone comes out of Intl — raced differentially against ICU's own longOffset strings across 418 zones and 20,436 transitions: https://dev48.infy.uk/solve/day71-dst-wall-clock-resolver.html
The finding is positional, not numeric
compatible, the default disambiguation, is not one policy. In a fold it behaves as earlier; in a gap it behaves as later. It always moves forward along the timeline of real instants, which is coherent and which no caller is ever told.
Put that together with the ordering above and half of every fold becomes arithmetically unreachable. Calendar arithmetic ends by resolving a wall time, and resolving a wall time in a fold returns the first of the two instants — so no date-unit duration, from any start, forwards or backwards, can land on the second. Over every fold in the database: 0 of 10,203 reachable by six date-unit routes, 10,203 of 10,203 by a single time-unit one. The control is the point — the instant is one PT1H away and always has been.
From 2025-11-01T01:30 in New York, P1D and PT25H both read 2025-11-02T01:30 on the clock. They are 3,600,000 ms apart.
The three shortcuts, scored over 490,464 cases
| model | wrong, transition-adjacent |
|---|---|
| exact-ms — "a day is 86,400 seconds" | 25.00% |
| wall-all — add everything to the wall clock | 18.78% |
| time-first — right spaces, wrong order | 4.17% |
The zeroes are the tell. exact-ms is perfect on every pure-time duration and wrong on half of every date duration; wall-all is its exact complement; time-first is wrong nowhere except on durations that mix the two halves, which is the one shape nobody writes a test for. All three are right on all 245,232 cases away from a transition, which is exactly why they ship.
Two more that cost money: midnight is absent on 1,580 dates across 160 zones and happens twice on 351 dates across 36, so anything computing a day boundary by concatenating T00:00:00 is silently an hour out, and still parses.
What the measurement contradicted
The page already carried a claim that timeZoneName:'longOffset' was lossy — that ICU rounds to whole minutes and would flatten Africa/Monrovia's -00:44:30. It does not. ICU 77.1 renders GMT-00:44:30, seconds intact, and agreed with offset-by-subtraction on 40,872 of 40,872 samples.
The real cost is arity, not precision: that one field emits four different string shapes, including a bare GMT with no sign and no digits for zero offset. A regex written against the shape you happened to test returns NaN for UTC, in a function whose output is a number. I had written the opposite on this page before testing it, which is the whole reason the verifier exists.
67 reference cases, all passing. One file, inline CSS, no external asset of any kind.
Part of a from-scratch series — one tool a day, all client-side, dependency-free engine: https://dev48.infy.uk/solvefromzero.php
Top comments (0)