Why we change the clocks, who does it, where it came from—and how a one‑hour shift can still break modern software.
A quick story to set the scene
At 2:07 a.m. on a chilly November Sunday, your on‑call phone buzzes: CPU on a billing server just spiked, jobs are running twice, and log entries look like they’ve time‑traveled. You check the timeline and see two different events stamped 1:42:17 a.m. What happened? It’s “fall back.” The 1 o’clock hour has just repeated, your cron schedule ran the same job in both copies of that hour, and downstream systems are now arguing about which 1:42 came first. Welcome to Daylight Saving Time (DST)—a civil‑time convention that still surprises distributed systems.
What is Daylight Saving Time?
Daylight Saving Time is a seasonal adjustment to local civil time. Clocks are advanced by one hour in spring (often at 2:00 a.m. jumping to 3:00 a.m.) and set back by one hour in autumn (2:00 a.m. back to 1:00 a.m.). The idea is to “move” an hour of daylight from morning to evening during longer days.
DST rules are not universal and are set by governments. Operating systems and applications implement those rules through the IANA Time Zone Database (often called tz, tzdata, or the Olson database), which defines how each named zone (e.g., America/New_York, Europe/Paris) behaves across history.
Why do we do it?
The original motivations mixed wartime resource management and evening daylight for commerce and recreation. Germany introduced DST in 1916 during World War I; the United States followed in 1918. Since then, supporters have argued that later sunsets boost retail foot traffic and outdoor activity. Critics counter that energy savings are inconsistent, the biannual shift disrupts sleep and safety, and the complexity isn’t worth it. Regardless of the pros and cons, DST endures because it’s embedded in law and habit.
Where is DST observed—and where isn’t?
Fewer than half of countries observe DST. In the United States, most states switch, but Hawaii and most of Arizona do not. U.S. territories—Puerto Rico, Guam, American Samoa, the U.S. Virgin Islands, and the Northern Mariana Islands—remain on standard time year‑round. Even within Arizona there’s nuance: the Navajo Nation observes DST; the surrounding Hopi Nation does not. Europe largely still changes clocks, although proposals to discontinue the practice recur regularly.
How it’s administered (and why the rules keep changing)
After a patchwork post‑WWII era, the U.S. Uniform Time Act of 1966 standardized DST nationally. Congress later adjusted the calendar: 1986 moved the start earlier; the Energy Policy Act of 2005 extended DST beginning in 2007 to the second Sunday in March and ending the first Sunday in November. Under current U.S. law, states may remain on permanent standard time without federal approval, but they cannot adopt permanent DST unless Congress says so—hence perennial “lock the clock” bills that rarely become law.
A deeper timeline
- 1916–1918: First widespread adoptions during WWI (Germany first; U.S. in 1918).
- 1942–1945: U.S. nationwide “War Time” during WWII.
- Post‑1945: Local choice creates a confusing checkerboard of observance.
- 1966: Uniform Time Act sets national framework.
- 1986 & 2007: Date tweaks produce today’s U.S. schedule.
This stop‑start history is why software must carry historical rules for each region. The tz database encodes not just today’s rules, but every change across decades—because old timestamps must still parse correctly.
Impact on networks and computing
Ambiguous and skipped times. In spring, a whole local hour (e.g., 2:00–2:59) never occurs; in fall, that hour repeats. Schedulers must choose whether a 2:30 a.m. job should run zero times (spring) or twice (fall). Many do the latter by default.
Logs and metrics. Duplicate local timestamps in the fall can scramble order. Prefer UTC for storage and include offsets when rendering for humans.
Databases. Distinguish between timestamp with time zone and without time zone. Store canonical UTC (ideally with time zone awareness) and convert at query or presentation layers.
APIs and queues. Cross‑region systems can drift around transitions. Use ISO 8601 in UTC (e.g., 2025-11-02T06:30:00Z) on the wire.
Calendars and meetings. Recurring events must be anchored to an IANA zone so that future legal changes apply automatically. Keep tzdata updated on clients, servers, and containers.
Patching and compliance. Governments sometimes change rules with short notice. Treat tzdata like a security dependency and roll updates promptly to avoid split‑brain time interpretation across a fleet.
Practical guidance for engineers and ops
- Favor UTC internally; convert to local time at the edges for people.
- When you need wall‑clock behavior (e.g., “9 a.m. New York time”), use IANA zone IDs, not fixed numeric offsets.
- Avoid scheduling critical jobs inside the transition window (01:00–03:00 local).
- Test around transition dates in staging; document how your scheduler behaves.
- Monitor and update tzdata regularly.
- In incident runbooks, call out DST behavior explicitly (especially for crons, batch jobs, and timed locks).
The ongoing debate
Health and consistency concerns keep the “abolish the time change” conversation alive in North America and Europe. But until laws change, DST remains a fact of civil time that engineers must design around. If your system touches human schedules, commerce, or compliance, plan for DST—and verify it every fall and spring.
