What Happens When the Clocks Change for DST?

Spring forward: the 23-hour day

At 01:59:59 on the second Sunday of March, North American clocks do not tick to 02:00. They jump to 03:00. The hour between 02:00 and 02:59 never appears on any wall clock. That day has 23 hours.

Europe runs the same pattern on the last Sunday of March, but the local times differ. In Europe, the jump is from 01:59:59 UTC+0 to 03:00:00 UTC+1. In North America, it is from 01:59:59 EST (UTC-5) to 03:00:00 EDT (UTC-4). The effect is identical: one entire hour of local time is erased from the calendar.

This is not a metaphor. If you schedule a meeting for 02:30 on that day, the meeting does not happen. The time never arrives.

Fall back: the 25-hour day

On the first Sunday of November, North American clocks go from 01:59:59 EDT (UTC-4) to 01:00:00 EST (UTC-5). The same hour, 01:00 to 01:59, plays out twice.

On the last Sunday of October in Europe, the same thing happens: 02:59:59 CEST (UTC+2) becomes 02:00:00 CET (UTC+1), and the 02:00 hour runs twice.

That day has 25 hours. You get an extra hour of sleep, or an extra hour of work, depending on your shift.

The missing hour: 02:00 becomes 03:00

The spring-forward shift creates what programmers call an "invalid local time." Any wall clock time between 02:00 and 02:59 on that day simply does not exist in the local time zone.

If a user types "2026-03-08 02:30" into a form, the computer faces a problem. That datetime is not representable in the America/New_York zone. Different systems handle this differently: - Some throw an error. - Some silently shift the time forward to 03:00. - Some shift it backward to 01:30. - Some accept it as a "flexible" time and store the UTC equivalent of 03:00.

The safest approach: reject the input and tell the user why. The second safest: treat it as 03:00 in DST and log the adjustment.

The duplicate hour: 01:00 happens twice

The fall-back shift creates the opposite problem: an "ambiguous local time." The wall clock time 01:30 on the first Sunday of November in New York occurs twice, once at 01:30 EDT (UTC-4) and once at 01:30 EST (UTC-5). Both are valid local times, but they refer to two different moments, one hour apart.

If a user enters "2026-11-01 01:30" without specifying which occurrence they mean, your software has to guess. Most systems assume the first occurrence (the DST instance) or the second (the standard time instance). Both are wrong half the time.

The fix: when storing future events, keep the local time plus the IANA zone identifier (like "America/New_York") and the UTC offset that was in effect when the user entered it. Never store just the local time and zone without the offset. Why Store Dates in UTC has more on this.

How computers handle the shift

Your computer does not "know" what time it is. It knows two things: 1. The current instant, measured as seconds since 1 January 1970 00:00:00 UTC, the Unix epoch. 2. The time zone configured in your operating system, usually an IANA zone identifier like "America/Chicago" or "Europe/Paris."

When you call Date.now() in JavaScript, the browser reads the OS clock's epoch time and the OS's time zone setting. It then applies the IANA database rules for that zone to produce the local time string you see on screen. How Browsers Determine Your Local Time explains the full chain.

During a DST change, the IANA database tells the computer exactly when the shift happens. The computer does not guess. It knows that on 8 March 2026 at 02:00:00 America/New_York, the UTC offset moves from -5 to -4. It applies that rule to every local time calculation.

This is why fixing your clock manually during DST is a bad idea. The computer already knows the change schedule. If you alter the clock, you break the mapping between the epoch instant and the local display.

Does spring forward fall back affect health, accidents and markets?

The Monday after spring-forward sees a measurable spike in traffic accidents, heart attacks, and workplace injuries. The data comes from decades of hospital and police records: the missing hour of sleep compounds with the disrupted circadian rhythm to produce a real, if small, public health event.

Financial markets also feel the shift. The overlap between London and New York trading hours changes because London moves its clocks on a different Sunday than New York does. During the two weeks in March when New York is already on EDT but London is still on GMT, the overlap window shifts by one hour. Traders who forget this lose money.

How to prepare for the change

For your personal schedule: - Spring-forward Saturday: go to bed at your normal time. Do not stay up late. Accept that Sunday morning will feel early. - Fall-back Sunday: enjoy the extra hour. Your body clock will not notice.

For your code: - Never store local time alone for future events. Store the IANA zone and the UTC offset at the moment of entry. - Validate user-entered times against the zone's change table. Reject invalid local times. Ask the user to clarify ambiguous local times. - Use a library that understands the IANA database. Do not write your own DST logic. - Test your scheduled jobs around the change dates. A cron job set for 02:30 on spring-forward day will not run. A job set for 01:30 on fall-back day might run twice.

For your team: - Announce the change dates two weeks ahead. Remind colleagues that meetings scheduled during the missing or duplicate hour need manual review. - If you work across Europe and North America, create a shared calendar showing both zones' change dates. The mismatch creates a two-week window where the offset difference is not the usual value.