Booking across time zones
How to book across time zones without confusing customers
By ByTomorrow · Published
Two people can agree to “nine in the morning” and mean different instants. A calendar display preference may make the time look right to staff while the customer's confirmation still uses another setting.
Use a two-zone confirmation record tied to the actual date. The examples below are illustrative conversions, not real appointments or proof that a particular integration has been tested.
What to distinguish
Avoid these misleading shortcuts
A zone abbreviation replaces a location and date
Short labels can be ambiguous, and a fixed offset can become wrong for another part of the year. Use the named zone and the appointment date in the scheduling system.
A display change is mistaken for a booking fix
HighLevel states that its viewing-time-zone preference changes how appointments appear, not availability or confirmation logic. Check each part separately.
Working worksheet
Make the rule and evidence explicit
Confirmation record
Copy appointment reference; appointment date; customer's named time zone; customer-local start; business/staff named time zone; staff-local start; stored instant with offset; confirmation wording; verification owner. Ask rather than infer the customer's zone from a phone number.
Suggested spoken confirmation
Use: “This is [full date] at [time] in [customer's named location/time zone]. For our team in [location], that is [date and time]. Is that the time you intended?” Include both dates when conversion crosses midnight.
Two fictional seasonal examples
Using named-zone conversion, 09:00 in America/Los_Angeles on October 20, 2026 is 09:00 in America/Phoenix. On November 20, 2026, 09:00 in Los Angeles is 10:00 in Phoenix. These calculations demonstrate why copying one fixed difference across dates can fail.
Separate the settings to inspect
Check the source appointment instant, staff display, public booking view, confirmation message and reminder message. Google Calendar documents event time zones and local display. Seeing the right time in one interface does not prove every message is correct.
Ambiguous or missing local times
Around a daylight-saving transition, a local clock time can repeat or be unavailable. Ask the scheduler to resolve the intended instant using the system's supported zone controls. Do not silently choose an occurrence or shift the customer's request.
Test matrix
Use cases in the same zone, different zones, different local dates, dates on both sides of a seasonal change and a rescheduled appointment. Record the stored instant and both displayed times for each case.
Use and verify
Check the result in the actual workflow
Confirm the requested location/time zone
Make it explicit before selecting a slot.
Convert for the appointment date
Use the scheduling system's named-zone rules, not mental arithmetic from last month.
Verify the stored appointment
Compare its identifier and instant with the intended customer-local time.
Inspect the actual confirmation
Read the message or calendar invitation the test recipient receives.
Repeat after rescheduling
A new date can change the relationship between local times. Reconfirm rather than copying the old message.
Questions
Straight answers.
HighLevel documents that it does not. Inspect the actual confirmation configuration and delivered test message.
Ask the person which time zone they intend. This guide does not treat a phone number as evidence of their location.
No. Conversion answers which instant was intended. Verify that the correct appointment actually exists using the separate booking-success checks.
Sources and further reading
- HighLevel appointment viewing time zone
HighLevel states that the viewing-time-zone preference changes display, not availability, booking links or confirmation logic.
Checked .
- Google Calendar and time zones
Google documents event time zones and displaying calendar events in local time zones. Date-specific conversion must use the applicable zone rules.
Checked .
Bring one process to review
Use the worksheet with your existing records and tools. Agree on the expected behavior, owner and verification before making a change.
Discuss your workflow