Daylight Saving Time Transition Checklist
Test meetings, jobs, timestamps, and local inputs safely when clocks move forward or backward in a named time zone.
Why transition days need separate testing
Most dates in a zone have an ordinary one-to-one relationship between local clock time and an instant. A daylight-saving transition breaks that assumption. During a forward change, part of the local clock is skipped. During a backward change, part of the clock repeats under two different UTC offsets. A calculation that works on an ordinary Tuesday can therefore reject, shift, or duplicate an event on a transition day. Identify every named zone involved and test its actual transition dates rather than using one country-wide assumption.
Find the applicable rule for the exact zone
Use the IANA zone connected to the real location, such as America/New_York or Europe/Paris. Do not infer the rule from an abbreviation or from another city that happens to share today’s offset. IANA regions can have different histories and future schedules even when their clocks currently match. Inspect the next transition, including the offset before and after it, and remember that governments can revise future rules after software or operating-system time-zone data has been released.
Handle nonexistent local times explicitly
When clocks jump forward, a value inside the skipped interval does not identify a real instant. If a zone moves from 01:59:59 to 03:00:00, then 02:30 is nonexistent on that local date. A safe interface should report that the time is invalid or ask the user to choose a valid time. Silently moving the input forward can change a legal cutoff, scheduled job, or travel plan without the user noticing. Record the validation rule in tests and user-facing documentation.
Handle repeated local times explicitly
When clocks move backward, a local value can occur twice. The first occurrence uses the earlier UTC offset and the second uses the later offset. “01:30” alone is therefore ambiguous. Resolve it with an explicit offset, a fold or occurrence choice, or a previously known UTC instant. If the application cannot represent the choice, stop and ask rather than guessing. Logs should include UTC or an offset so two events with the same displayed local time can still be ordered correctly.
Test recurring events and automated jobs
For a recurring 09:00 local meeting, retain the IANA zone and recalculate each occurrence so the meeting stays at 09:00 after the offset changes. For a job intended to run every 24 elapsed hours, anchor the schedule to an instant or UTC-based interval; its local display time may move. Also test daily jobs scheduled inside the skipped or repeated interval. Decide whether the system skips, runs once, runs twice, or moves the job, and make that behavior observable.
Communicate the transition to people
A calendar may convert correctly while the written message remains misleading. Include the full date, local time, IANA zone, and UTC equivalent when a meeting or deadline is close to a transition. Mention that another participant’s local time may change even if the organizer’s time does not. For travel or operational handoffs, compare the departure zone and destination zone independently because their transitions can occur on different dates.
Minimum transition test set
Test one instant immediately before the change, the boundary itself, one value inside any gap or repeated interval, and one instant immediately after. Repeat the set for both forward and backward changes. Confirm the local date, UTC offset, abbreviation, DST state, and round-trip conversion back to the original instant. Add an ordinary winter and summer date as controls. Re-run the suite after updating the operating system or time-zone database, and confirm policy-sensitive future dates with the relevant authority.
Questions fréquentes
What is a nonexistent local time?
It is a clock value skipped during a forward transition and therefore does not map to an instant in that zone.
Why can a local time occur twice?
A backward transition repeats a clock interval, with each occurrence using a different UTC offset.
Should software guess which repeated time was intended?
No. It should obtain an offset or occurrence choice, or apply a clearly documented domain rule.
Do all zones change clocks on the same dates?
No. Participation and transition dates vary by region and can be changed by governments.
Références principales
Ces normes et pages officielles étayent les définitions et règles présentées. Les politiques horaires et calendriers peuvent évoluer ; confirmez les dates critiques auprès de l’autorité compétente.
- Référence IANA Time Zone Database theory
- Référence NIST Daylight Saving Time rules
- Référence RFC 5545: Internet Calendaring and Scheduling