Daylight Saving Time (DST) — Impact on Software and Scheduling
Understand how daylight saving time affects software, scheduling, and timestamp calculations. Learn about DST transition edge cases and how to handle them in code.
Fundamentals
Detailed Explanation
Daylight Saving Time and Its Impact on Software
Daylight Saving Time (DST) is the practice of advancing clocks by one hour during warmer months to extend evening daylight. While the concept is simple, its impact on software is surprisingly complex.
When Does DST Occur?
DST transitions vary by country and hemisphere:
- Northern Hemisphere (US, Canada, EU): Spring forward (March/April), fall back (October/November)
- Southern Hemisphere (Australia, Brazil): Spring forward (September/October), fall back (March/April)
- Many countries don't observe DST at all: Japan, China, India, most of Africa, etc.
The "Spring Forward" Problem
When clocks spring forward, one hour is skipped. For example, in US Eastern time, 2:00 AM becomes 3:00 AM. This means:
1:59 AM EST → (one minute passes) → 3:00 AM EDT
Times between 2:00 AM and 2:59 AM do not exist on that day. If your software creates a scheduled event at 2:30 AM on the spring-forward day, it will fail or behave unexpectedly.
The "Fall Back" Problem
When clocks fall back, one hour is repeated. For example:
1:59 AM EDT → (one minute passes) → 1:00 AM EST
Times between 1:00 AM and 1:59 AM occur twice on that day. If a user says "1:30 AM on November 3rd," it is ambiguous — it could be EDT or EST.
Common Bugs
- Duration calculations: A day is not always 24 hours. On DST transition days, it is either 23 or 25 hours.
- Recurring events: A daily meeting at 2:30 AM will break on the spring-forward day.
- Cron jobs:
30 2 * * *will skip once in spring and run twice in fall. - Date arithmetic: Adding "1 day" to 2024-03-09 11:00 PM (US Eastern) should give 2024-03-10 11:00 PM, not midnight.
Safe Practices
- Store timestamps in UTC — never store local times
- Use IANA timezone IDs — not offsets
- Use proven libraries — Temporal API, Luxon, date-fns-tz, Joda-Time
- Test DST transitions — write unit tests for spring-forward and fall-back days
- Avoid scheduling during transition hours — if possible, schedule between 3 AM and midnight
Use Case
DST awareness is critical for scheduling applications, calendar systems, alarm clocks, flight booking systems, financial transaction processing, and any system that calculates durations spanning DST transitions. A one-hour error can mean missed flights, incorrect billing periods, duplicate cron job executions, or missed SLA windows.