Learning Objectives
By the end of this lesson you will be able to:
- Explain how Daylight Saving Time (DST) works in spring and fall
- Identify what happens to the missing hour when clocks spring forward
- Identify what happens during the repeated hour when clocks fall back
- Design test cases for scheduling bugs that occur at DST transition times
What Is Daylight Saving Time?
Daylight Saving Time is the practice of advancing clocks by one hour during summer months so that daylight occurs later in the day. Most countries that observe DST spring forward in March or April and fall back in October or November. The exact dates vary by region — the United States transitions on the second Sunday in March and the first Sunday in November; the European Union transitions on the last Sunday in March and the last Sunday in October.
Not all countries observe DST. Japan, China, India, and most of Africa do not. This means that the UTC offset for a timezone that observes DST is not constant — it changes twice a year.
Spring Forward: The Missing Hour
In the spring transition, at 2:00 AM the clocks jump directly to 3:00 AM. This means:
- 1:59 AM → 3:00 AM (the next minute after 1:59 is 3:00, not 2:00)
- 2:00 AM through 2:59 AM do not exist on that day in that timezone
Any event scheduled for 2:30 AM on a spring-forward day does not exist. Systems that schedule events must handle this edge case explicitly. Common bugs include:
- Scheduled jobs missing: A cron job set to run at 02:30 every morning silently skips the DST transition day because that time does not exist. The next execution is the following night.
- Appointment booking errors: A booking system allows users to book a 2:30 AM slot on the transition day. The stored UTC time is ambiguous (which 2:30 AM did the user mean?). On retrieval, the local time conversion may show 3:30 AM instead.
- Infinite loops: A timer loop that sleeps until a target time and then increments by 1 hour may loop backward if the "next hour" does not exist.
Fall Back: The Repeated Hour
In the fall transition, at 2:00 AM the clocks jump backward to 1:00 AM. This means:
- 1:00 AM occurs twice — once before the transition and once after
- Any time between 1:00 AM and 1:59 AM is ambiguous on that day: it could be before or after the clock was set back
The repeated hour creates a different set of bugs:
- Duplicate events: A scheduled report that runs every hour at :30 past runs at 1:30 AM (pre-transition) and then again at 1:30 AM (post-transition) — two executions instead of one.
- Incorrect duration calculations: A user logs in at 1:15 AM (before fall-back) and logs out at 1:45 AM (after fall-back). Naively subtracting times gives 30 minutes, but the actual session duration was 1 hour 30 minutes because an hour repeated in between.
- Ambiguous log timestamps: Two log entries both show 1:30 AM but refer to different physical moments. Without a timezone offset in the log, you cannot tell which is which.
Test Cases for DST Transitions
Spring-forward tests (on the transition day):
- Submit a booking for 2:30 AM and verify the system returns an error or normalizes the time to 3:30 AM, not silently accepts it.
- Verify that a scheduled task set for 2:00 AM either skips the day or runs at 3:00 AM (not at an unexpected time or never).
- Verify that a duration calculation spanning midnight on the transition day accounts for only 23 hours, not 24.
Fall-back tests (on the transition day):
- Submit a booking for 1:30 AM and verify the system asks the user to clarify which 1:30 AM (pre or post transition), or documents which one it defaults to.
- Verify that a scheduled task set for 1:30 AM runs exactly once, not twice.
- Verify that a duration calculation for a session that spans the repeated hour computes the correct duration (adding 1 extra hour for the fall-back).
UTC as the DST-Safe Storage Format
Storing all timestamps in UTC eliminates DST ambiguity entirely. In UTC:
- 2:30 AM always exists (UTC does not observe DST)
- 1:30 AM occurs only once (no repeated hour in UTC)
Convert to local time only when displaying to the user — at that point, the presentation layer applies the DST rules. The backend data remains clean, unambiguous UTC.