Scheduling software gets timezones wrong

Twice a year, a quiet catastrophe hits the service industry: appointments shift by an hour, staff show up to empty rooms, customers arrive to locked doors. The cause isn't human error. It's booking software that stored "Tuesday 2pm" as a naive timestamp and let daylight saving move it.

Timezones are the most underestimated problem in scheduling software. Everyone thinks it's solved — it's a clock, how hard can it be — and then the clocks change.

Why slots drift

The naive approach: store the appointment as an absolute instant (a UTC timestamp). Tuesday 2pm Pacific becomes 21:00 UTC. When daylight saving ends and Pacific goes from UTC-7 to UTC-8, that 21:00 UTC is now 1pm Pacific. The appointment drifted an hour, silently, for every recurring booking on the calendar.

The correct approach: store the wall-clock time plus the timezone rules, and resolve to an instant at booking time. Tuesday 2pm America/Los_Angeles stays Tuesday 2pm through every clock change, because the timezone database knows when the offsets shift. This is well-understood computer science — and a shocking amount of shipping software still gets it wrong.

Availability windows beat slot grids

Most booking tools show you a grid of slots: 9:00, 9:30, 10:00. But the grid is a lie if it isn't validated against reality — staff schedules, breaks, existing bookings, holidays, the class that runs long on Thursdays. A slot that exists on the grid but not in anyone's actual availability is a double-booking waiting to happen.

The honest model: availability windows first (when is this staffer actually here?), then slots generated inside the windows, then every booking validated against the windows — not just against other bookings. Round-robin assignment makes this harder, not easier: the intake answers and the availability both have to travel with the assignment.

The deposit problem

Paid bookings add money to the time problem. A deposit is a financial event attached to a temporal one: if the appointment moves, the deposit has to follow; if it's cancelled, the refund policy has to execute; if there's a coupon, the discount has to land on the deposit, not the headline price, or your books record fiction.

This is why the calendar and the money need to be separate systems that talk to each other — the booking engine and the account ledger, each doing its job. Bolt the payments onto the calendar and you get neither right.

Reminders: the cheapest feature with the best ROI

The no-show is the most expensive appointment: staff idle, room empty, revenue zero. SMS and email reminders are the least glamorous feature in scheduling software and the highest-ROI one — a text message the day before recovers revenue that no amount of slot-grid polish can. If your booking tool doesn't remind automatically, you're paying for the tool and still doing the tool's job.

The honest caveat

No booking engine fixes a business that overbooks its people. DST-safe slots, validated windows, automatic reminders — they're leverage on a well-run schedule, not a substitute for one. And the domain question matters less than the reliability question: customers will forgive booking at yoursite.com vs theirs, but they won't forgive the appointment that moved an hour without telling them. Get time right first. Branding is downstream of trust.

---

Creytix Scheduling is multi-tenant scheduling and booking: DST-safe slots, classes with waitlists, SMS/email reminders, and Stripe deposits that post to the client ledger — on your domain. See the pricing — buy it or rent it, your call.