The customer was on time. Your booking app wasn’t.

Imagine arriving for the appointment in your confirmation email, then being told you missed it an hour ago. You moved a meeting, arranged the trip and followed the instructions. The business now has you down as a no-show.

In this hypothetical, the customer's email says 9 a.m. and the staff calendar says 8 a.m. Somewhere between the booking, the calendar and the reminder, the software disagreed with itself. Calling the customer unreliable would be a remarkably convenient conclusion.

If your business sells appointments, classes or scheduled visits, the time you send is part of the service you promised. It deserves a better acceptance test than a calendar screen that looks right today.

A useful deadline for checking your bookings

In U.S. locations that observe daylight saving time, clocks go back on November 1, 2026, at 2 a.m. local time. The hour beginning at 1 a.m. happens twice. The rule does not apply everywhere in the country. NIST's current daylight saving time rules.

That is a reason to test now, not a prediction that your system will fail. A properly designed booking system should handle the transition without asking customers to understand it. The useful question is whether your team has checked the complete journey, including the messages already waiting to go out.

A weekly 9 a.m. booking is a promise about local time

Consider a recurring Monday appointment at 9 a.m. in New York. Under the current time-zone rules, these two occurrences correspond to different UTC times:

• October 26: 9 a.m. in New York is 13:00 UTC.
• November 2: 9 a.m. in New York is 14:00 UTC.

If an implementation takes the first UTC timestamp and adds exactly seven 24-hour days, the next occurrence lands at 8 a.m. in New York. The arithmetic is consistent. It does not preserve the customer's weekly 9 a.m. appointment.

These are calculated examples, not a report about a particular booking product. They illustrate why a recurring local schedule needs its time zone and recurrence rule preserved. MDN explains the distinction between named time zones, changing offsets and ambiguous local times in its time-zone documentation.

Most customers will never book during the repeated overnight hour. They can still be affected by a recurring schedule or a reminder calculated using the wrong offset. Testing only a normal afternoon appointment created and attended on the same day misses that class of error.

“We store everything in UTC” leaves a question unanswered

UTC is useful for identifying an exact instant. It cannot, by itself, tell the next developer whether you meant “every Monday at 9 a.m. at this location” or “exactly 168 hours after the previous event.” Those instructions happen to agree much of the year.

For a recurring local appointment, retain the local scheduling intent and a named zone such as America/New_York. Resolve each occurrence under the applicable rules. For a fixed instant, preserve that instant and display it clearly in the relevant local zone. Decide what should happen to future bookings if the region's rules change.

Those rules are maintained data, not permanent constants. IANA updates the Time Zone Database when governments change offsets, boundaries or daylight saving rules. Your software and operating-system updates are part of keeping that data current. IANA Time Zone Database.

The business must also decide whose clock matters. A visit to your premises usually needs the premises' local time. A video call may show each participant a different local time for the same instant. Someone travelling with their phone should not accidentally move the underlying booking just by opening your app.

Follow the booking beyond the calendar screen

Ask the team maintaining your system to create a test booking before the clock change for a date after it. Use a test customer and controlled email or SMS destinations. Follow that booking through the customer confirmation, staff calendar, calendar invitation, reminder queue and attendance record.

Every display should agree about the actual appointment, even when participants see different local times. The date and relevant zone should be understandable without the customer doing a conversion. Keep the booking's identifier available to support so staff can compare the records.

Then change that booking. The original reminder may already be queued. A calendar event may be cached on someone's device. Checking only that the new time saved successfully tells you little about the instructions the customer will receive.

• Move one occurrence of a recurring booking. Check the changed date, the remaining series and the staff view.
• Cancel after a reminder has been scheduled. Verify that the obsolete reminder is cancelled or suppressed before sending.
• Open the booking from a device in another time zone. Check both the displayed time and whether editing it preserves the intended appointment.
• If you offer overnight bookings, test the repeated hour. On November 1 in New York, “1:30 a.m.” needs enough information to identify which occurrence you mean. Make that choice explicit.

Do these checks in an isolated test environment. Changing a production server's clock to see what happens is a poor way to investigate your customers' calendar.

Keep enough evidence to resolve a disagreement

A customer-facing confirmation, its appointment version and the time it was sent help staff investigate a disputed no-show. So do the booking's change history, the zone used for display and the reminder's delivery record. “The message sent successfully” proves much less than “the customer received the correct appointment details.”

If those records disagree, pause the automatic blame. Give staff a way to correct the attendance status and handle any disputed fee under your policy. Sending another reminder with the same wrong time will only make the failure more efficient.

This is not an argument for building a calendar engine from scratch. A maintained scheduling service or library may do most of the difficult work. Your integration still has to preserve its meaning when it copies events, queues notifications and handles changes.

If your booking app, CRM and reminders disagree, tell Rosecraft which systems are involved and where the time changes. We can help trace the problem, define the expected behaviour and implement the fixes.

Ready to hear what needs fixing rather than who to blame? Send us the workflow. Your customer should not have to prove they followed your own instructions.