Configured local times can disappear.
Example Page
DST Critical Cases
Daylight saving time is not just a display problem. It creates missing local times, repeated local times, and duration drift that can break payroll, reporting, and batch processing if boundary logic is vague.
day-boundary API.
The same wall-clock time can happen twice.
The same scheduled span can end at different exact instants.
Spring-Forward Gap
On Sunday, March 8, 2026 in America/New_York, local
02:30 does not exist. A fixed boundary at that time
needs an explicit policy rather than an implicit crash.
Fall-Back Ambiguity
On Sunday, November 1, 2026 in America/New_York, local
01:30 happens twice. If you collapse those into one
timestamp, duration math can silently go wrong.
| Policy | Local timestamp | Exact instant | Resolved window |
|---|
Duration Drift
An overnight shift can be eight actual elapsed hours or an
00:00 -> 08:00 local wall-clock schedule. On a fall-back
night, those are not the same thing.
What To Lock Down
Policy checklist- Always require an explicit IANA time zone.
- Choose a skipped-time policy for spring-forward boundaries: default resolution or fail fast.
- Choose an ambiguous-time policy for repeated fall-back timestamps:
earlierorlater. - Keep window identity based on exact
startandend, not wall-clock labels alone. - Decide whether your business rule means elapsed duration or wall-clock schedule before doing payroll math.
- Derive reporting labels such as
Logical_Datedownstream from the resolved window, usually fromwindow.start.