Scheduling a Shopify sale: time zones, DST and midnight

Every autumn the same support message arrives in slightly different words: “the sale went live an hour before it should have”. Sometimes it is an hour late. Sometimes it is the end that moved rather than the start. Nobody typed the wrong time. What changed is the meaning of the time they typed, and the culprit is either a clock change or the quiet assumption that everyone involved, the merchant, the store, the server and the customer, shares a time zone.

This post is about that assumption. It explains what a scheduled time actually is inside a Shopify store, why the clock change that sits between now and Black Friday matters more than most merchants expect, and how SafeSale stores and executes the times you give it.

A schedule is an instant, not a clock reading

When you type “27 November, 00:00” into a form, you are describing a wall-clock reading. Computers do not store wall-clock readings; they store instants, points on a single global timeline usually expressed in UTC. Somewhere between your keyboard and the database, something has to turn the reading into an instant, and to do that it needs a time zone. Whichever zone it picks is the one your sale will follow.

There are three candidates, and they are often not the same zone. The browser you are sitting at has one. The store has one, set under Settings, General in the admin, and it is the zone Shopify uses when it shows you order times and discount schedules. And your customers have their own, one each, none of which the store knows anything about until they check out. A merchant living in Lisbon whose store is set to New York time, running a sale for German customers, is juggling three zones before anything has gone wrong.

SafeSale makes one specific choice here and says so under the date fields: times are in your browser’s time zone. If you are in Lisbon and schedule 00:00, the sale starts at Lisbon midnight, and the app stores that as the instant it corresponds to. It does not silently reinterpret the reading in the store’s zone. Whether that is the zone you wanted is a question worth asking before you confirm, and the summary shown at confirmation is the place to ask it.

The clock change hiding in the BFCM calendar

In 2026 the European Union and the United Kingdom leave summer time on Sunday 25 October. The United States and Canada end daylight saving time on Sunday 1 November. Black Friday is 27 November and Cyber Monday is 30 November. So a merchant who sits down in mid-October to schedule the season’s sales does so on summer time, for dates that will be on standard time. Australia goes the other way, moving its clocks forward on 4 October in the states that observe it, and a lot of the world, including Mexico since 2022 and most of Asia and Latin America, does not change at all.

Whether this matters depends entirely on how the scheduling software did the conversion. Done properly, a wall-clock time typed in October for a date in November is converted using the offset that will apply in November, and the sale starts at the midnight you meant. Done lazily, by taking today’s offset and applying it to a future date, the sale is off by an hour, in a direction that depends on the hemisphere.

Modern browsers get this right when the field is a proper date-time input and the code asks for the instant rather than doing arithmetic on offsets, which is what SafeSale does. The place the lazy version still turns up is spreadsheets and hand-written scripts: a column of “start times” built by adding a fixed number of hours to a date will be wrong for exactly the dates that fall after the clock change.

Midnight where?

The second confusion is not about software at all. A sale that starts at 00:00 in your zone starts at 00:00 in your zone and nowhere else. For a store selling into one country that is fine. For a store using Shopify Markets to sell into Europe and North America from one catalogue, “midnight on Black Friday” is a six-hour spread, and the customer in Los Angeles sees the sale go live at 3 p.m. on Thursday.

There is no setting that fixes this, because the stored price of a variant is one number and an automatic discount is one rule, active or not. What you can do is decide deliberately. Some stores schedule for the midnight of their largest market and accept the spread. Some start the sale at the earliest midnight across their markets, so nobody sees it late. Some run the sale from Thursday evening in Europe to Monday night in California and stop caring about the edges, which for a four-day event is usually the right call. What does not work is scheduling for “midnight” without saying whose.

If you are running several sales for different regions, as we described in running a Black Friday bulk sale without compounding, remember that SafeSale will not let two sales claim the same variant. Regional timing is done with separate sales on separate products, or with one sale and a long window, not with overlapping sales on the same items.

How SafeSale stores and runs a schedule

Two details of the implementation are worth knowing, because they decide what happens when things go wrong.

• The instant is stored, and checked every 30 seconds. When you confirm a sale with a start in the future, SafeSale records the exact instant and creates a start job for it, plus an end job if you set an end. A scheduler wakes every 30 seconds and runs any job whose time has come, so a sale starts within half a minute of the scheduled moment. A start time in the past starts the sale as soon as you confirm; the button even changes from “Schedule sale” to “Start sale” so you can see which one you are about to do.
• Automatic discounts carry their own dates. In automatic-discount mode the start and end you set are written onto the discount inside Shopify, and Shopify enforces them. If the SafeSale server were unreachable at 00:00, the discount would still switch on and off at the right instants, because Shopify is the one holding the clock. This mode requires an end date for that reason: a discount without an end is a discount nobody is scheduled to remove.
• Price rewrites are reverted by a job. In strike-through mode the sale price is written into the variant and the original goes to compare-at, so ending the sale means writing the snapshot back. That is a job on our side, retried with backoff if Shopify is slow and reported as “Needs attention” if it cannot complete, which is the behaviour we tested in what happens when a discount app is down on Black Friday. The revert uses the snapshot taken before the sale, never the current price, so a late revert restores the right number even if the timing slipped.

A pre-flight check for the season

None of this needs a spreadsheet. It needs about five minutes per scheduled sale, done once, before the clocks change.

1. Open Settings, General, and read the store time zone out loud. Then check the time zone of the computer you schedule from. If they differ, decide which one is “the” zone for this sale and write it in the sale name: “BF 2026 (CET)” saves an argument later.
2. Schedule the sale and read the confirmation summary. The start and end shown there are the instants SafeSale will act on, rendered in your browser’s zone. If the shown time is not what you meant, fix the picker, not the clock on your laptop.
3. Convert the start to the local time of your biggest market and ask whether that is when you want it to appear. Do the same for the end, which is usually the one nobody checks and the one that upsets customers when it lands early.
4. If the sale spans a clock change, as anything running from late October into November in Europe does, expect the sale to be one hour longer or shorter than the naive count of days times 24. This is correct behaviour; it only looks odd in a report.
5. On the morning of the start, check the sale list. A scheduled sale shows “Scheduled” with its start instant, then “Live” once the job has run. If it is live an hour before you expected, you now know exactly which of the three zones to blame, and the price snapshot means the fix is an edit, not a rebuild.

The trick with time zones is not to be clever. It is to write down which one you mean, once, and let the software store the instant. SafeSale stores the instant. The writing-down part is yours.