OPERATIONS · MAY 5, 2026 · 5 MIN READ

Booking software and time zones — getting it right for global customers

By Zedule May 5, 2026

Time-zone bugs are responsible for a meaningful share of customer complaints in booking software. The classic failure: customer in London books a 2pm slot; the business in New York sees it at 9am; everyone is confused.

For service businesses with customers in multiple time zones — online lessons, virtual consultations, travel- adjacent services, cross-border B2B — getting this right matters.

Why time zones are hard

Three challenges:

1. Detecting the customer’s time zone

Browsers report the customer’s local time zone via Intl.DateTimeFormat().resolvedOptions().timeZone. This works ~99% of the time but breaks for:

Customers using VPNs (browser reports VPN location)
Customers traveling (laptop set to home time zone)
Customers with mis-set system clocks

2. Storing time correctly

Bookings should be stored in UTC, not local time. Display logic converts UTC to whichever time zone the viewer needs.

If a booking is stored as “2pm” without time zone context, you’ve lost data. The booking is ambiguous forever.

3. Daylight saving transitions

Time-zone offsets change twice a year in many countries. A customer booking “2pm UK time” in March might have meant 2pm GMT or 2pm BST depending on the booking date.

Storing as (UTC time, customer time zone name) — e.g., (2026-05-15T13:00Z, Europe/London) — handles DST automatically.

What good booking software does

Properly handled:

Booking page detects the customer’s time zone automatically, but lets them override.
Time slots show in the customer’s time zone by default. The customer sees “2pm your time” not “2pm our time”.
The business sees bookings in their time zone automatically.
Reminders go out at the right local time. Sent at 24 hours before the appointment in the customer’s time zone, not the business’s.
Calendar invites have a time zone field. When the customer adds the booking to their calendar, it stays correct across DST changes.

Common bugs to watch for

Bug 1: Reminders at wrong hour

Customer in London books 9am UK time. Business in New York. Reminder sent “24 hours before” lands at 4am UK time because the platform calculated 24 hours from business-local time.

Fix: send reminders relative to customer-local time.

Bug 2: Available slots in wrong time zone

Customer browses available slots; the booking page shows “9am, 10am, 11am” without specifying time zone. Customer assumes their local; actually shown in business time. Booking is wrong.

Fix: always show time zone next to time. “9am EST” not just “9am”.

Bug 3: Calendar invite not DST-aware

Booking made in March before DST shift; stored as a fixed UTC offset. Comes April, the time displays an hour off in the customer’s calendar.

Fix: store with time-zone name (Europe/London), not just offset (UTC+0).

Bug 4: Business time-zone changes

Business moves locations or changes time zones. Past bookings still need to be interpretable; future bookings might not be.

Fix: each booking is stamped with the business’s time zone at booking time.

What to test in a platform

Before committing to a platform, verify:

Set your laptop time zone to a non-default zone (e.g., Tokyo). Open the booking page. Are slots shown in Tokyo time?
Book a slot. Look at the confirmation email. Does it say what time zone?
As the business, look at the booking. Is it in your time zone?
Schedule a reminder for 24 hours before. Does the reminder land at customer-local time or business-local?

If the platform fails any of these, you’ll get support tickets in production.

Storage best practices

For the database design (relevant if you’re building or integrating):

CREATE TABLE bookings (
  id PRIMARY KEY,
  business_id NOT NULL,
  customer_id NOT NULL,
  start_time TIMESTAMPTZ NOT NULL,  -- UTC
  duration_minutes INTEGER NOT NULL,
  business_timezone TEXT NOT NULL,  -- e.g., 'America/New_York'
  customer_timezone TEXT,           -- e.g., 'Europe/London'
  ...
);

Three fields capture the necessary information:

start_time — definitive UTC moment
business_timezone — for displaying in business context
customer_timezone — for displaying in customer context, for reminders

Reminder timing

For a booking starting at start_time:

24-hour reminder: send at start_time - 24h, but rendered in customer’s TZ
2-hour reminder: send at start_time - 2h

This is straightforward UTC arithmetic. The complication is rendering: the message shows “tomorrow at 2pm” in customer-local language.

Quiet hours

Don’t send reminders before 9am or after 8pm in the customer’s time zone. A customer in India getting a 2am SMS for a 9am US-time appointment hates you forever.

Compute quiet hours per customer, not per business.

Multi-time-zone businesses

Some businesses (online tutoring, virtual coaching) have customers across many time zones simultaneously. The booking page should:

Show availability in the customer’s TZ
Show the staff member’s TZ on the booking page (“Maria’s local time: 8pm”)
Make the time-zone difference clear before confirmation

This prevents the “did I really agree to a 3am call?” confusion.

Edge cases

Customer changes time zones (travels) after booking. The booking is at a fixed UTC moment. The reminder should go to the customer’s current time zone if detectable, otherwise the booking-time TZ.
Daylight saving on appointment day. Rare but happens. Stored as (UTC, TZ name), displayed correctly.
Time zones with non-standard offsets. India is UTC+5:30; Nepal is UTC+5:45; some Australian zones shift mid-state. Most date libraries handle these.