How Daylight Saving Time Works
Follow what happens when clocks move forward or back and how software handles the transition.
The forward transition
When a region advances its clock, a range of local wall times is skipped. If clocks jump from 01:59 to 03:00, a requested local time such as 02:30 does not exist on that date in that zone.
The backward transition
When clocks return to standard time, a range of wall times occurs twice with different UTC offsets. A local value such as 01:30 is ambiguous unless an offset, sequence choice or exact instant is also supplied.
Conversion versus arithmetic
Adding hours to a UTC instant and displaying the result in a zone is different from adding hours to a local wall clock. The correct operation depends on whether elapsed duration or local schedule time should stay constant.
Recurring events
A meeting fixed at 09:00 New York time should retain America/New_York so its UTC time can move with local rules. A system job fixed to 14:00 UTC should remain tied to UTC even when participants change clocks.
Testing transition dates
Applications should test dates immediately before, during and after both transitions. Use current IANA data and define how nonexistent or repeated local inputs are handled instead of silently guessing.
Distinguish clock arithmetic from elapsed duration
Across a spring clock advance, two local clock labels that look two hours apart may identify instants only one elapsed hour apart. Across a backward change, a one-hour-looking local interval can take longer, or the repeated labels may need an offset to distinguish them. To measure elapsed duration, resolve each endpoint as an instant and compare the UTC values. To schedule a local recurring event, preserve the intended local clock and zone, then resolve each date separately. The planner uses actual elapsed minutes for its meeting duration and evaluates the whole interval against local working hours. It does not assume that every local day is exactly twenty-four elapsed hours. Mixing a local-clock recurrence with a fixed elapsed interval is a common way to shift a reminder unexpectedly after a seasonal change.
Use two UTC inputs to inspect a repeated hour
Enter November 1, 2026 at 05:30 UTC with America/New_York as the destination, then repeat with 06:30 UTC. Under the installed rules, both display 01:30 locally, but their numeric offsets differ. This experiment isolates the repeated-hour problem without asking a software library to guess which local occurrence you meant. The two UTC inputs remain distinct when exported to a calendar event. In the meeting table, a repeated source hour appears twice with its offset, while a missing spring hour has no valid row. If you are reviewing a log that discarded the offset and only saved the local clock, do not claim that you can reconstruct the order from those incomplete labels alone. Look for a retained UTC timestamp, sequence identifier, or other evidence before interpreting the event order.
Create operational tests instead of a one-time explanation
Turn the transition examples into a repeatable checklist for each important zone. Confirm that nonexistent local input is rejected, that repeated local input is treated as ambiguous, and that a UTC-selected occurrence converts back consistently. Test a meeting that starts within working hours but finishes after the closing boundary: it should not be classified as fully available. Include a Sunday transition so the weekend policy is tested independently from the clock change. When rules are updated, rerun the date-specific tests and investigate differences rather than freezing old outputs merely to keep a test green. Keep the time-zone database version with diagnostic notes, but do not describe that version as universally current unless you have checked it. The site displays its installed version so its behavior can be inspected without implying that future policy changes are impossible.
Frequently asked questions
What is a nonexistent local time?
It is a wall-clock value skipped when clocks move forward.
Why can one local time occur twice?
The backward transition repeats a clock interval under two different UTC offsets.
Should recurring meetings be stored only in UTC?
Retain the IANA zone when the meeting is meant to stay at the same local wall time.
Primary references
These standards and official pages support the definitions and rules discussed above. Time-zone policies and published calendars can change, so consult the responsible authority for critical future dates.
- Reference IANA Time Zone Database theory
- Reference NIST Daylight Saving Time rules