Daylight Saving Time Explained: How DST Affects Unix Timestamps
Daylight saving time shifts local clocks forward in spring and back in autumn. Unix timestamps are immune (they always count UTC), but every conversion between Unix time and local time has to know whether DST is active. This guide covers what DST is, where it applies, the gap and overlap bugs it creates, and how to handle it correctly.
What is daylight saving time?
Daylight saving time (DST) is the practice of advancing local clocks by one hour during part of the year to extend evening daylight. About 70 countries currently observe it, mostly in temperate latitudes. The transition is a discontinuity in wall-clock time, not in UTC — Unix timestamps continue to tick forward smoothly through every spring-forward and fall-back.
- Northern hemisphere: clocks usually go forward in March and back in October/November
- Southern hemisphere: clocks go forward in October and back in March/April
- Tropical and equatorial regions generally do not observe DST
- DST adds an extra hour to evening daylight but does not change the total amount of daylight
How DST transitions affect Unix timestamps
A Unix timestamp is the number of seconds elapsed since 1970 UTC, so it cannot skip ahead or repeat. What changes is the local-time interpretation of those seconds. At a spring-forward transition, the local clock jumps from 02:00 to 03:00 — the wall-clock hour from 02:00 to 02:59 never occurs locally. At fall-back, the local clock from 01:00 to 01:59 happens twice with a one-hour gap in UTC.
- No Unix timestamp is ever skipped or duplicated by DST
- A given Unix timestamp maps to one specific local time, including the offset (PDT vs PST, BST vs GMT, etc.)
- A given local time may map to zero (DST gap) or two (DST overlap) Unix timestamps
- Use IANA names (America/Los_Angeles) so DST is applied for you; never hard-code an offset like UTC−8 if the location observes DST
DST gap and DST overlap explained
The DST gap (spring-forward) is the most common source of bugs in scheduling and reminder systems — an event set for 02:30 on the transition day will not exist locally. The DST overlap (fall-back) is the less obvious bug: an event at 01:30 on the transition day exists twice. Either case requires an explicit policy.
- Gap: spring-forward removes a wall-clock hour. ISO 8601 / RFC 3339 cannot represent times inside the gap unambiguously
- Overlap: fall-back makes one wall-clock hour repeat. Annotate which occurrence with an explicit offset (UTC−5 vs UTC−4)
- Python: zoneinfo handles gap/overlap via the fold attribute (0 = first occurrence, 1 = second)
- JavaScript Temporal: ZonedDateTime methods take a disambiguation option ("earlier", "later", "compatible", "reject")
- Cron jobs at 02:30 in DST-affected zones either skip on spring-forward or fire twice on fall-back — schedule in UTC if possible
Which regions observe DST
DST adoption is patchwork. The following is broadly accurate for 2026 but changes regularly — always consult the current IANA tzdata.
- United States: most states observe DST (March–November). Arizona (except the Navajo Nation) and Hawaii do not
- Canada: most provinces observe DST. Saskatchewan, most of Yukon, and (since 2026) most of British Columbia do not
- European Union: observes DST (last Sunday of March → last Sunday of October). A 2019 vote to abolish DST has been deferred
- United Kingdom: observes DST as BST (UTC+1) in summer
- Mexico: abolished nationwide DST in 2022; only border municipalities aligned with the US still observe it
- Australia: only NSW, Victoria, Tasmania, ACT, and South Australia observe DST (October–April)
- Most of Asia, Africa, and South America: no DST
Handling DST safely in code
The reliable approach is to anchor everything on Unix timestamps (or IANA-zoned date-times) and treat local time as a presentation concern.
- Store: Unix epoch seconds or a timezone-aware datetime (e.g. TIMESTAMPTZ in Postgres)
- Compute: in UTC or in IANA-aware date-time libraries (Temporal, zoneinfo, java.time)
- Display: convert to the user’s IANA timezone at render time
- Schedule: store the IANA timezone alongside the local wall-clock for recurring events that should remain at "9 a.m. local"
- Never store the abbreviation EDT/PDT/CET as a substitute for the IANA name
The push to abolish DST
Multiple legislatures have voted to abolish biannual clock changes; few of those votes have led to actual policy changes. Notable recent activity:
- 2022: US Senate unanimously passed the Sunshine Protection Act, which stalled in the House
- 2022: Mexico abolished nationwide DST
- 2024: Trump publicly opposed permanent DST; Senate momentum slowed
- 2026: British Columbia became permanently UTC−7; the US House Energy and Commerce Committee advanced fresh DST-abolition language
- 2019: EU voted in principle to abolish DST but has repeatedly delayed implementation
Daylight saving time FAQ
- Does DST affect Unix timestamps?
- No. Unix timestamps count UTC seconds since 1970 and continue smoothly through every DST transition. Only the local-time interpretation of those seconds changes.
- What happens to scheduled jobs at the DST transition?
- A cron job in a DST-affected zone scheduled at 02:30 will either be skipped (spring-forward) or run twice (fall-back). The fix is to schedule in UTC or use a scheduler that disambiguates explicitly.
- Is "EST" or "America/New_York" the right thing to use in code?
- America/New_York. The IANA name automatically applies EST (UTC−5) in winter and EDT (UTC−4) in summer. Hard-coding "EST" means values are wrong half the year.
- When does DST start and end in 2026?
- In the United States, DST begins at 02:00 local on March 8, 2026 (spring-forward to 03:00) and ends at 02:00 local on November 1, 2026 (fall-back to 01:00). In the EU, the transitions are March 29 and October 25, 2026.