Daylight Saving Time Ends November 1, 2026: How to Stop Time Zone Bugs in Your Code

At 2:00 a.m. on Sunday, November 1, 2026, most of the United States sets its clocks back to 1:00 a.m. Most people get an extra hour of sleep. Software gets an hour that happens twice and a day that is 25 hours long. Every year that breaks something: a nightly job runs twice, a report counts one hour's revenue twice, or an "add one day" helper returns 11 p.m. on the same day. This guide covers what actually happens to the clock, the five bugs it causes most often, and the rules that prevent them.

What happens at 2:00 a.m.

Take New York (America/New_York). Before the change the offset is UTC−4 (EDT). At 2:00 a.m. EDT the local clock jumps back to 1:00 a.m. and the offset becomes UTC−5 (EST). So every local time from 1:00:00 to 1:59:59 happens twice, an hour apart in real time:

The wall-clock time is the same, but the timestamps are 3,600 seconds apart. Paste both timestamps into the Timestamp Converter and you get two different moments with the same local label. A local time without an offset is ambiguous for one hour a year, and in the spring there is an hour of local times that never happen at all. In 2027 the clocks spring forward on March 14, and 2:30 a.m. that morning won't exist.

Not every American clock moves

The US has no single rule. Your code should use the time zone database rather than assume one:

• Arizona (America/Phoenix) stays on UTC−7 all year and does not observe DST. The Navajo Nation, inside Arizona, does observe it.
• Hawaii (Pacific/Honolulu) stays on UTC−10 all year.
• Puerto Rico, Guam, the US Virgin Islands, American Samoa and the Northern Mariana Islands don't change their clocks.
• Most of Mexico abolished DST in 2022, but the border cities (Tijuana, Ciudad Juárez, Matamoros and others) still follow the US schedule. Mexico City doesn't change; Tijuana does.
• The UK falls back a week earlier, on October 25, 2026. For that one week, London is four hours ahead of New York, not five. Recurring transatlantic meetings end up off by an hour.

Congress has seen repeated bills to make daylight saving time permanent. None has become law, and the clocks still change on November 1. That uncertainty is one more reason to rely on the IANA time zone database, which is updated when governments change their rules, instead of writing the rules into your own code.

Bug 1: "add 24 hours" is not "add one day"

November 1, 2026 is 25 hours long in every US zone that observes DST. Code that adds 86400000 milliseconds to get "tomorrow" lands in the wrong place:

// Run with TZ=America/New_York
const start = new Date(2026, 10, 1);        // Sun Nov 01 2026 00:00 EDT
new Date(start.getTime() + 86400000);       // Sun Nov 01 2026 23:00 EST  ← same day!

const next = new Date(start);
next.setDate(next.getDate() + 1);           // Mon Nov 02 2026 00:00 EST  ✓

Use calendar arithmetic (setDate, or your date library's addDays) when you mean calendar days, and millisecond arithmetic only when you mean elapsed time. The two are the same on 363 days of the year, which is why tests rarely catch the difference.

Bug 2: the cron job that runs twice (or not at all)

A job scheduled for 1:30 a.m. in a DST-observing zone meets that local time twice on November 1, and a 2:30 a.m. job has no matching time at all on the spring-forward date. Whether the job runs twice, once, or not at all depends on the scheduler: some cron implementations handle the change specially and some don't. Don't rely on either behaviour:

• Run servers and schedulers in UTC, where there is no DST and no repeated hour.
• If a job has to follow local business hours, use a scheduler with explicit time zone support and read how it handles skipped and repeated times.
• Make jobs idempotent, so a second run on the same day does nothing harmful. Record the date you processed and skip it if it's already done.
• Don't schedule anything important between 1:00 and 3:00 a.m. local time in a DST zone.

Bug 3: hard-coded offsets

"2026-12-01T09:00:00-04:00" is not "9 a.m. New York time". In December New York is at −05:00, so that string means 8 a.m. there. An offset is a snapshot. A time zone is a rule. Store and pass around IANA names such as America/Chicago and let the runtime work out the offset for each date:

new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/Chicago',
  year: 'numeric', month: 'short', day: 'numeric',
  hour: 'numeric', minute: '2-digit',
  timeZoneName: 'short'
}).format(new Date('2026-11-01T07:30:00Z'));
// "Nov 1, 2026, 1:30 AM CST"

Abbreviations are just as unreliable as inputs. "CST" means Central Standard Time in the US, China Standard Time in Beijing, and Cuba Standard Time in Havana. Use abbreviations for display, never for parsing.

Bug 4: parsing an ambiguous local time

If a user types "Nov 1, 2026, 1:30 a.m." into a New York form, the value has two possible meanings. JavaScript's Date quietly picks the earlier one (EDT, 05:30Z). That may or may not be what the user meant. For bookings, shift handovers and billing cut-offs, handle the case on purpose: store the offset the user confirmed, or ask. The new Temporal API, which is rolling out in JavaScript runtimes, lets you pick with a disambiguation option ('earlier', 'later', 'reject'). Until it's available everywhere, use a date library that exposes the same choice.

Bug 5: hourly reports with 23 or 25 buckets

A dashboard that groups events by local hour will have a 25-row day on November 1 and a 23-row day in March. If the code assumes 24 rows, it drops data or shifts every hour after 1 a.m. Group by UTC hour and convert labels for display, or key buckets on the full offset-aware timestamp so the two 1 a.m. hours stay separate.

The rules that prevent all five

• Store instants in UTC (ISO 8601 with Z, or Unix timestamps) for logs, events, created-at fields and anything that has already happened.
• Store future local events as wall time plus an IANA zone (for example 2027-03-15 09:00 + America/Denver). If the government changes the rules before that date, the meeting stays at 9 a.m. local time.
• Keep the time zone database updated in your OS images, language runtimes and containers. Old tzdata is behind many "wrong by one hour" reports.
• Test the transition dates: freeze the clock at 2026-11-01T05:59:59Z and 06:00:00Z for New York, and at March 14, 2027 for spring forward, and assert on the results.
• Timestamps must be seconds or milliseconds, consistently. Mixing them up is the other classic time bug. We cover it in the JWT guide.

Useful ToolzYard tools

Conclusion

Daylight saving time bugs are predictable: they appear on two dates a year, in the same small set of patterns. Record moments in UTC. Keep future local events as a wall time plus an IANA zone. Use calendar arithmetic for calendar days, keep schedulers off the 1–3 a.m. window, and test the transition dates before November 1, not after.