On November 1, half past one happens twice

Two dates to put in the calendar now

Twice a year, a lot of software quietly does something odd for an hour. In 2026 the autumn change lands on two dates. Across the EU and the UK, summer time ends at 01:00 UTC on Sunday, October 25. In most of the United States, daylight saving time ends at 2:00 AM local time on Sunday, November 1, when the clock goes back to 1:00 and that hour repeats. Hawaii and most of Arizona don't change, and neither do Puerto Rico and some other territories.

That gives you an hour on each date when 1:30 AM happens twice. In March it goes the other way and 2:30 AM doesn't happen at all.

Most apps get through this without anyone noticing. The ones that don't usually fail in small, confusing ways: a reminder sent twice, a nightly job that ran at the wrong time, a report with an extra hour of orders in it, a booking slot that shows up twice on a calendar. None of it is dramatic. All of it ends up as a support ticket on a Monday morning, and someone loses an afternoon working out what happened.

This is a checklist for the next two weeks. Go through it with whoever runs your web app, or send it to them.

Find everything that runs on a clock

Start with a list. You can't check what you haven't found. Ask your developer, or look yourself, for anything that happens at a time rather than because someone clicked:

• Scheduled jobs: nightly imports, exports, backups, invoice runs, data syncs.
• Reminders and notifications: appointment reminders, renewal notices, "your cart is waiting."
• Booking and availability: slots, opening hours, delivery windows, staff shifts.
• Deadlines: "submit by midnight," offer expiry, payment due dates, cancellation cut-offs.
• Reports and dashboards: anything that says "today," "yesterday" or "per hour."
• Third-party tools that run on your behalf: email platforms, payment processors, warehouse systems.

For each item, write down two things: what time it's set for, and which clock that time is on. That second question is the one that matters. "2:00 AM" set in UTC behaves completely differently from "2:00 AM" set in New York time. If nobody knows which clock a job uses, that's your first finding.

Check the jobs that run in the night

Scheduled jobs set in local time between 1:00 and 2:00 AM are the classic trouble. On the November date, a job set for 1:30 AM local may run twice, once in each 1:30. On the March date, a job set for 2:30 AM may not run at all, depending on the scheduler.

Go through the list and check:

• Any job scheduled between 1:00 and 3:00 AM local time. Can it safely run twice? Can it safely be skipped?
  
• Jobs that aren't safe to repeat, like invoicing, charging cards or sending payouts. Move them out of that window, or schedule them in UTC.
  
• Jobs that pick up "everything since the last run." Do they track the last run by a timestamp with a time zone, or by a local clock time that's about to repeat?
  
• Jobs that finish by a time ("done before the morning shift"). An extra hour in November is harmless; a missing hour in March can push a slow job past its deadline.
  

If you only fix one thing, fix the money jobs. A reminder sent twice is annoying. A card charged twice is a refund, an apology and maybe a chargeback.

Check bookings, deadlines and reminders

Anything a customer sees with a time on it needs a second look.

• Bookings. Can someone book a slot at 1:30 AM on November 1? (If you run anything overnight, such as deliveries, support or care work, you may have real slots there.) Which 1:30 do you mean? Most calendars show it once and quietly pick one.
  
• Recurring appointments. A weekly 9:00 AM appointment should stay at 9:00 AM local time after the change, not drift to 8:00 or 10:00. This is the most common visible bug: a recurring time stored as a fixed offset from UTC instead of a local time in a named zone.
  
• Deadlines. "Midnight" in whose time zone? If your customers are in more than one zone, the deadline should say which one, on the page and in the email.
  
• Reminders. "24 hours before" across a clock change is either 23 or 25 hours on the wall clock. Decide which one customers expect; usually it's "same time the day before."
  

A time without a time zone is a guess that happens to be right most days. The clock change is when the guess gets checked.

Check the reports

Reports are where the clock change hides best, because the numbers look plausible.

• Daily totals. November 1 has 25 hours in most of the US. If someone compares that day's orders with the Sunday before, the extra hour is in there. Not wrong, but worth a note on the report so nobody celebrates it.
  
• Hourly charts. Does the 1 AM bar include both 1 AMs? Does March's chart show a gap at 2 AM, or a zero that looks like an outage?
  
• "Yesterday." Is it calculated in the business's time zone, the server's, or UTC? If the server is in UTC and the business is in Chicago, "yesterday" has always been slightly off. The clock change just makes it visible.
  
• Exports to accounting. If the finance team's numbers and the app's numbers disagree for the first week of November, this is often why.
  

Fix it once, then test the date

The long-term fix is boring and well known. Store times in UTC, along with the time zone they belong to (a named zone like America/New_York, not a fixed offset like UTC−5). Convert to local time only when showing it to a person. Schedule money jobs in UTC, or at hours that never repeat or vanish, like 4:00 AM. For recurring appointments, store the local time and the named zone, and calculate each occurrence from those.

Then test it. Most systems let a developer set a test clock to a chosen date. Run your scheduled jobs, your booking calendar and your reminder logic as if it were 12:30 AM on November 1 and step through to 3:00 AM. Do the same for the second Sunday in March, which in 2027 is March 14. An hour of testing now is cheaper than a Monday of tickets.

If your app is used in Europe and the US, you get two rehearsals: October 25 shows you what November 1 will do.

We build web applications that handle bookings, deadlines and scheduled work for businesses in more than one time zone. If you'd like a second pair of eyes on yours before the clocks change, talk to us.

Related work: PatientIQ.