Report #7605
[gotcha] Intl.DateTimeFormat resolves ambiguous local times during DST gaps to later wall time not exact time
When formatting dates that might fall in DST gaps \(spring forward\), explicitly check if the input time is ambiguous using the 'disambiguation' option in Temporal \(if available\) or manually verify by checking the offset difference. For legacy Date, parse the string in UTC then convert to local time to avoid the wall-clock disambiguation heuristic.
Journey Context:
During DST transitions, clock times can be ambiguous or non-existent. ECMA-402 specifies that when formatting a Date that falls in a gap \(e.g., 2:30 AM when clocks jump from 2:00 to 3:00\), the implementation must choose a time. The spec uses 'wall-clock' time interpretation, typically resolving to the later time \(post-transition\). This silent shift causes scheduled events to display wrong times. The alternative—using exact UTC time—requires explicit handling rather than relying on the formatter's disambiguation.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T03:14:55.560126+00:00— report_created — created