How to prepare ecommerce operations for the clock change

The week the clocks disagree

The clock change is treated as a domestic inconvenience and is actually a scheduling event with a defined blast radius, because the United States and Europe do not change on the same date.

In 2026 the European Union and the United Kingdom put their clocks back on Sunday 25 October. The United States does it a week later, on Sunday 1 November. For those seven days the offset between any US city and any European city is one hour away from the value everyone has memorised, and every recurring calendar invite, every scheduled report and every support-coverage rota that was set by hand rather than by timezone is wrong by exactly that hour.

What actually breaks

The failures cluster in three places, and none of them announce themselves. Recurring meetings drift, because a calendar entry created in one timezone and read in another resolves differently once one side has changed and the other has not. Scheduled jobs misfire: a task set for 01:30 local time runs twice on the day the clocks go back, because that hour occurs twice, and any job that writes a record rather than reading one will write it twice. And reporting quietly deforms, because the day the clocks fall back is twenty-five hours long and the day they spring forward is twenty-three, so a like-for-like daily comparison across that boundary is comparing different amounts of time.

Fix it in dependency order

Work outward from the layer that everything else depends on: data first, then automation, then anything a customer sees.

Store and compare in UTC, and treat local time as a presentation concern rather than a storage one — most of the reporting damage comes from systems that recorded a wall-clock time and lost the offset. Then audit anything that runs on a schedule, paying particular attention to jobs set between 01:00 and 03:00, which is the window that repeats or vanishes. Only then look at customer-facing promises: dispatch cut-offs, delivery windows, live-support hours and the send time of anything automated. Doing it in the other order produces a customer-facing fix sitting on top of data that is still wrong.

How to know it worked

Compare the transition day against the same weekday a fortnight earlier, in UTC, and check that the totals move for reasons you can name.

The single most useful check is whether your daily orders figure shows an unexplained bump on 1 November and an unexplained dip in March. If it does, the pipeline is bucketing by local wall-clock time and the twenty-five-hour day is being counted as a normal one. It is a small distortion in isolation and it compounds: it lands in the year-on-year comparison, in any model trained on daily data, and in the week the finance team uses to explain the month.

The failures that look like something else

The dangerous failures are the ones that get attributed to something else.

A duplicated overnight job that sends a notification twice reads as an email bug. A dispatch cut-off that moves by an hour reads as a warehouse problem. A drop in European meeting attendance during the gap week reads as people being busy. In each case the real cause is a one-hour offset that nobody is looking for, and the investigation goes somewhere expensive instead. The other genuine risk is the fix itself: hard-coding an offset to correct a symptom leaves a system that will be wrong again in five months and wrong in the opposite direction.

What this looks like on the day

In practice the work is small and specific. One person spends an afternoon listing every scheduled job with its trigger time and timezone. Anything in the 01:00-03:00 window is either made idempotent or moved. Recurring cross-border meetings are recreated with an explicit timezone rather than a fixed hour. Customer-facing cut-off times are checked against the timezone they are actually evaluated in, which is frequently the server's rather than the customer's. Then it is left alone until March, when the same list is reused.

The case for ignoring all of this

The reasonable objection is that this is an hour, twice a year, and most businesses survive it without noticing. Modern platforms handle timezones correctly by default, cloud schedulers are usually UTC-based, and calendar software resolves invitations properly when both parties have timezone support switched on. Spending a week preparing for a one-hour shift is a poor use of attention for most teams.

That holds for a single-market operation and stops holding the moment orders, staff or suppliers sit on both sides of the Atlantic — which is the situation of anyone selling across marketplaces in more than one region. It also assumes the defaults were never overridden, and in practice they usually were, by somebody who needed a report to arrive at nine in the morning and hard-coded it. The cost of checking is an afternoon. The cost of not checking is an investigation that starts in the wrong place.

Why the gap week exists at all

The European Union moves on the last Sunday of October and the United States on the first Sunday of November. In most years those are different dates, and in 2026 they are a week apart: 25 October and 1 November. The rules are set independently by each jurisdiction and have been changed several times, which is why the offset between two cities is not a constant you can safely hard-code.

This is also why the timezone database exists as a maintained public record rather than as a lookup table anyone can write once. Jurisdictions announce changes with varying notice, and systems that carry their own copy of the rules go wrong quietly when a rule changes and the copy does not.

The practical consequence for a distributed team is that the week between the two dates is the one where hand-written schedules break. If a recurring event matters during that window — a weekly ops call, a supplier cut-off, a reporting deadline — it is worth confirming rather than assuming.

The twenty-five hour day, and what it does to a chart

On 1 November the local day contains twenty-five hours, because the hour between 01:00 and 02:00 happens twice. Any metric aggregated by local calendar day therefore has an extra hour of accumulation in it, and any metric aggregated by hour has one bucket containing two hours of events or two buckets containing the same labelled hour.

For a low-traffic operation this is noise. For anything with a meaningful overnight volume it is a visible artifact, and it is the kind that gets explained rather than diagnosed — a small unexplained rise is easy to attribute to a campaign that happened to be running.

The fix is to aggregate in UTC and convert for display. Where that is not possible, the minimum is to annotate the two transition days in whatever dashboard the numbers are read from, so nobody builds an argument on a day that was not the same length as the ones beside it.

The customer-facing edge nobody checks

Dispatch cut-offs, delivery estimates and support hours are usually written as plain local times in a content system and evaluated somewhere else entirely. The question worth asking is which clock decides whether an order made the cut-off — the customer's, the warehouse's, or the server's — and whether anyone has confirmed the answer rather than assumed it.

Automated messages are the other exposure. A dispatch confirmation timed to send at a fixed hour will, on the transition day, either send twice or not at all depending on how the scheduler resolves the repeated hour, and both are visible to the customer in a way that internal reporting glitches are not.

None of this requires new infrastructure. It requires one person to list the places where a time is written down as a number, and to check which timezone that number is interpreted in. That list is short and it is almost never written.

A checklist for the six weeks before

Do the audit six weeks out, in one afternoon, and reuse the same list in March.

Week one, list every scheduled job with its trigger time and the timezone it resolves in, and flag anything between 01:00 and 03:00. Week two, make the flagged jobs idempotent or move them outside the window. Week three, recreate recurring cross-border meetings with explicit timezones and confirm anything landing between 25 October and 1 November. Week four, check dispatch cut-offs, delivery windows and support hours against the clock that actually evaluates them, and annotate both transition days in the dashboards before anyone reads a number off them.

Keep the list, not the memory

The output of this work is a written list of every place a time is hard-coded and which timezone interprets it. That list is what makes the March transition a ten-minute job instead of a repeat of the whole exercise, and it is the artefact that survives the person who made it leaving. Without it the same audit gets rediscovered twice a year by whoever is on call.

Review it before each transition and after any change to scheduling infrastructure or to the markets you sell in. Adding a market on the other side of a different DST boundary changes the gap week, and the assumption that quietly held for two years stops holding the quarter you expand.

Editorial conclusion

None of this is difficult and all of it is invisible until it costs something. The clock change is a known date with a known effect, which puts it in the small category of operational risks you can fully prepare for in an afternoon. The teams that get bitten are not the ones without sophisticated infrastructure; they are the ones where somebody once hard-coded an hour and nobody wrote it down.