How Should a Booking Web App Handle Customer and Business Time Zones?

A booking web app should store each appointment against a clear, named time zone, and it should show that zone wherever an appointment time appears to customers or staff. For fixed location appointments, the business location's zone is normally the one that matters. For remote appointments, you need to decide whether the customer's zone, the business zone, or both are shown. Daylight saving gaps and repeated times need an explicit rule before development starts, not a fix after launch.

This article is about one commissioning decision: whose clock does a booking follow? It is not about payments, reminders, exports or editing conflicts. It is general guidance for planning a project.

Start with the kind of appointment

The first question is where the appointment happens. The answer changes which zone is the anchor.

Fixed location appointments

If the customer must walk into a salon, clinic room, workshop or office, the appointment belongs to that place. A customer who is travelling and browsing from another country still arrives at the business at the business's local time. Recommendation: anchor these bookings to the business location's named zone and to show that zone name beside every time, even when the customer appears to be in the same zone.

If the business has more than one location, record the zone per location, not once for the whole account. Recording the zone per location keeps each site's times correct if a second site is added later.

Remote appointments

A video call, phone consultation or online lesson has no single place. Here you need to choose a rule and write it down. Two reasonable options:

1. Anchor the booking to the business zone and show the customer a converted time in their own zone as a helper.
2. Let the customer pick their zone and show availability in it, while the business still sees its own zone.

Option 2 is friendlier for customers abroad. Option 1 is simpler to build and easier to explain to staff. Either can work. The poor choice is to leave it undecided, because then each screen makes its own guess.

Choosing the display zone

A browser can format a time for a given zone and language. MDN documents the Intl.DateTimeFormat object, which enables language-sensitive date and time formatting. Its options let you name a zone and show the zone name, so the display can say which zone a time belongs to. MDN's examples include an option to make a zone name visible, which is useful for a booking screen.

Recommendations for the display layer:

• Show the zone name next to the time on the booking form, the confirmation and any reminder text.
• If a converted time is shown, label both clearly, for example the business time and the customer's time, instead of showing one unlabelled time.
• Keep the date format tied to the customer's language, but do not let language alone decide the zone. A German speaking customer may be anywhere.
• Do not silently use the device zone as the booking zone. Devices can be wrong, or the customer may be booking for someone elsewhere.

What the date and time input does not do

Many booking forms use the browser's date and time control. MDN notes that the datetime-local input is intended to represent a local date and time, not necessarily the user's local date and time. It also states that the control does not provide a way to set the time zone. MDN suggests handling the zone in a separate control, for instance a hidden value when the user is logged in with a known setting, or a select list when the user must choose.

For a commissioning brief, this means the zone is a separate piece of data that someone has to design. Ask your developer where the zone comes from on each form and where it is stored. If the answer is that it is implied, treat that as an open question.

MDN also warns that HTML form validation is not a substitute for scripts that ensure that the entered data is in the proper format. Time and zone values should be checked on the server too.

Daylight saving gaps and repeated times

Where a zone observes daylight saving, some local times do not exist in spring and some happen twice in autumn. MDN says the datetime-local input allows combinations that are invalid in the user's zone, such as the one hour within a daylight saving time spring-forward transition gap. So the browser will not protect you.

Ask for a written rule for both cases:

• Gap: a requested local time does not exist. Recommended rule: do not offer such slots at all, and reject them if submitted.
• Repeated time: a local time occurs twice. Recommended rule: if the business is open at that hour, either avoid offering the ambiguous slots or show them with a clear label of which occurrence they are, and store the exact moment, not only the clock text.

For an individual confirmed appointment, a simple safeguard is to store both the exact moment and the named zone, then generate the visible local time from those. Future recurring schedules, such as every Tuesday at 10:00, need a separate rule on whether the local clock time stays fixed when daylight saving changes. A stored moment alone does not settle that. Your developer will know the technical form. What you should insist on is that the rule is chosen by the business and tested with sample bookings.

Confirmation and admin view

The confirmation is the customer's proof of what was agreed. It should state the date, time, zone name and, for remote bookings, the converted time in the customer's zone. Where it makes sense, include the location address for fixed appointments.

The admin view should default to the business zone, label it, and let staff see the customer's zone on any remote booking. If staff work from several locations, decide whether the admin screen shows each booking in its own location zone or in one chosen zone, and label which one is active.

A hypothetical example

Imagine a small tutoring business that offers in person sessions at a studio and online sessions for families abroad. The owner chooses: studio sessions follow the studio zone and always show its name. Online sessions are anchored to the studio zone, and the booking page also shows the family's chosen zone as a second line. The confirmation lists both. The admin calendar shows studio time with a small badge showing the family's zone for online sessions. For the two daylight saving edge cases, the owner decides that nonexistent times are never offered, and ambiguous times are not offered for bookings at all. This is a hypothetical illustration of the decisions, not a report of a real project.

Acceptance checklist

Use this list when you write acceptance criteria for the project, and when you describe the scope in a project conversation.

• Each location has a stored named zone.
• Each remote booking has a documented anchor rule.
• Every appointment time shown to customers or staff shows its zone name.
• The zone is a separate, stored data field, not implied by the form.
• Server side checks reject invalid or nonexistent local times.
• The business has chosen a written rule for repeated times.
• Confirmation shows the zone and, for remote bookings, the customer's converted time.
• The admin view labels its zone and shows the customer's zone on remote bookings.
• Test bookings cover a gap, a repeated hour and a customer in another zone.

FAQs

Should I just use the customer's browser zone?

It is a reasonable starting suggestion for remote bookings, but let the customer confirm or change it. For fixed location appointments, the business location's zone is the better anchor.

Do I need to let customers pick a zone?

Only if remote customers in several zones are a real part of the business. If almost everyone is local, showing the business zone clearly may be enough.

Is a daylight saving rule really worth deciding early?

Yes, because it affects what slots are offered, what is stored and what the confirmation says. Writing the rule as one sentence in the brief means nobody has to guess it during development. For questions about obligations to customers, consult a qualified professional.