Daylight saving rarely breaks a one off appointment. Book something for next Tuesday, store it as an instant, and the clock change is handled without anyone thinking about it. What daylight saving breaks is recurring appointments, cross border meetings, and anything scheduled to land inside the transition hour itself.
Three separate things go wrong. A recurring series drifts by an hour if it was stored as a list of instants rather than as a rule. A cross border meeting shifts relative to one side for a week or more each spring and autumn, because countries do not change on the same date. And at the transition itself one local hour occurs twice and another does not exist at all, which breaks any code assuming a local time maps to exactly one instant. The foundations, storing instants and using IANA zone names, are in time zone handling in scheduling. This piece is about the transitions.
What Changes At A Transition
At a transition, a region shifts its offset from UTC, usually by an hour. Going forward, an hour of local time is skipped: the clock jumps, so a local time in that gap does not exist and cannot be converted to an instant. Going back, an hour of local time repeats: the same reading occurs twice, an hour apart, so a local time in that range maps to two instants and converting it needs a choice about which you meant.
Crucially, the instant timeline is unaffected. Time itself does not skip or repeat. It is only the labels that move, which is why systems that store instants survive transitions untouched and systems that store labels do not.
Why Recurring Appointments Are The Real Problem
A recurring appointment carries an intention a single booking does not: "every Tuesday at 10:00". The part that matters is 10:00, a wall clock reading, because the point of a recurring slot is that it holds its place in the working day.
If a series is expanded once into a list of UTC instants and those instants are stored, the series will hold its position relative to UTC and drift relative to the clock. A 10:00 meeting created in winter becomes an 11:00 meeting in summer. Nothing in the system looks wrong. Every individual booking is internally consistent. The series has simply lost the intention it was created with.
The fix is to store the rule, not the results: a local time, a recurrence pattern, and an IANA zone name. Instants are then computed from the rule whenever they are needed, so each occurrence resolves against the offset in force on its own date. A series that spans a transition produces occurrences on both sides of it that all read 10:00 locally, and that have different UTC instants, which is exactly right.
Two implications follow. Changing a series should change the rule, not each occurrence, or you reintroduce the drift by hand. And an occurrence moved individually becomes an exception attached to the rule rather than an independent booking, so the rest of the series keeps behaving. Setting up recurring appointments covers the mechanics.
Countries Change On Different Dates
This is the part that surprises people who have handled the basics correctly. Daylight saving is set nationally, and the dates do not line up.
| Region | Clocks Forward | Clocks Back |
|---|---|---|
| European Union and the United Kingdom | Last Sunday in March | Last Sunday in October |
| United States and Canada, where observed | Second Sunday in March | First Sunday in November |
| Australia, in the states that observe it | First Sunday in October | First Sunday in April |
| New Zealand | Last Sunday in September | First Sunday in April |
| Most of Asia and Africa, plus Arizona, Hawaii, Saskatchewan and Queensland | No change | No change |
Treat that table as the current published rules rather than permanent fact. Jurisdictions change their minds at short notice, which is why offsets should be read from a maintained time zone database at runtime rather than written into your own code.
The Weeks When A Cross Border Meeting Shifts
Put two of those regions together and you get periods where the usual gap between them is wrong.
Take a weekly call between London and New York, normally five hours apart. In spring, the United States moves forward on the second Sunday in March and the United Kingdom on the last Sunday in March. For the two or three weeks between, the gap is four hours rather than five, so a call at 14:00 London and 09:00 New York becomes either 14:00 and 10:00, or 13:00 and 09:00, depending on which side the series is anchored to.
That last clause is the whole issue. A recurring series is anchored in one zone, and the other side moves. There is no configuration that keeps both sides fixed, because the two countries have chosen different arrangements for those weeks. Something has to give.
The autumn version is shorter but the same in kind: Europe moves back on the last Sunday in October and North America on the first Sunday in November, leaving roughly a week where the gap is an hour off. Southern hemisphere pairs are worse, since Australia and New Zealand move in the opposite direction to Europe, so a London to Sydney gap shifts by an hour in each direction and has two mismatched windows on top.
Deciding Which Side Is Anchored
Since one side must move, decide which deliberately rather than letting the tool decide silently.
- Anchor to the host. The meeting stays put in the host working day, and the other party sees it move. Right for a service business where the appointment has to sit inside published hours.
- Anchor to the client. The client keeps their time and the host absorbs the shift. Right when the client is the constrained party, such as a fixed slot between two of their own commitments.
- Anchor to the majority. For a group meeting, anchor to the zone most attendees are in and warn the minority.
- Anchor to UTC. Both sides move by an hour twice a year. Rarely what anyone wants for a human meeting, but correct for automated processes and for anything that has to align with a market or a system.
Whichever you choose, say so. A calendar invitation that reads "10:00 America/New_York, note this is 15:00 in London until 30 March and 14:00 after" costs one line and prevents the missed call.
Ambiguous And Non Existent Local Times
At the transition hour itself, two edge cases appear, and they are the ones that produce errors rather than merely wrong answers.
The Hour That Does Not Exist
When clocks go forward, the skipped local hour has no instant. In the European Union that is 02:00 to 02:59 on the last Sunday in March; in the United States it is 02:00 to 02:59 on the second Sunday in March. Ask a date library to convert 02:30 on that date and you will get either an exception or a silent adjustment, depending on the library, and silent adjustment is the more dangerous of the two.
The right handling is not to offer those slots at all: slot generation should resolve each candidate local start to an instant and discard any that fail. For a recurring series whose local time falls in the gap on one occurrence, pick a policy and document it, and shifting forward to the first valid local time is the least surprising choice for most businesses.
The Hour That Happens Twice
When clocks go back, the repeated local hour maps to two instants. In the European Union that is 02:00 to 02:59 on the last Sunday in October; in the United States it is 01:00 to 01:59 on the first Sunday in November. A booking for 01:30 that day is genuinely ambiguous, and defaulting to the first occurrence, the one still on summer time, is the usual convention.
The practical answer for most booking pages is again to avoid the question. Few businesses take appointments at those hours, so skip the ambiguous local hour in slot generation and let the day run an hour longer with no bookable slots in that window. Where you genuinely operate overnight, hospitality and clinical rotas being the obvious cases, show the offset alongside the time so a client can pick the one they mean.
A Transition Week Checklist
- Check recurring series that cross the transition, especially those with participants in more than one country, and confirm the local times on each side read as intended.
- Warn the party who is moving. One email a week ahead naming the new local time for them.
- Check appointments in the transition hour itself. There should not be any, but confirm rather than assume.
- Check reminder timing for the days either side, particularly anything expressed as a local time rather than an offset from the appointment. See appointment reminder timing.
- Confirm your time zone database is current, on the server and in any application that ships its own copy.
- Spot check one synced calendar entry on each side of the change, since a sync integration is another place a local time can be reconstructed incorrectly. Why calendar sync fails covers the failure modes.
- Look at the first Monday after the change for a run of unexpected cancellations or late arrivals, which is the visible symptom of an hour going astray somewhere.
What Not To Do
- Do not adjust bookings manually after a transition. If you are shifting appointments by an hour by hand, something upstream is storing the wrong thing, and hand corrections make the next transition worse.
- Do not hardcode transition dates. They are governed by rules that change, and a hardcoded date is a bug with a delayed fuse.
- Do not assume offsets are whole hours. Some zones sit at thirty or forty five minute offsets.
- Do not test only in your own zone. If your zone does not observe daylight saving, none of these cases will appear in testing while appearing constantly for your clients.
How appntmnts.io Handles Transitions
appntmnts.io stores one off bookings as instants and recurring series as rules with an IANA zone name, so occurrences resolve against the offset in force on their own date and a weekly slot holds its place in the host working day across a transition. Booking pages render in the visitor zone with the zone labelled, and calendar sync exchanges instants in both directions so an appointment created in Google Calendar or Microsoft 365 lands on the hour it was created for.
The Google Calendar integration page covers how the sync exchanges times, and pricing shows what the free plan includes. If you have not settled the storage question yet, read time zone handling in scheduling first, because every problem in this article is easier once that part is right.