Why a booking page shows the wrong timezone

Short answer

A booking page shows the wrong timezone when three clocks disagree: the city saved on the page, the city the guest's browser reports, and the city on the calendar that receives the event. The slot is one moment. It looks wrong only when those three are not the same city.

TimeTuna's timezone page names the symptom: the meeting was booked for 10am, but it showed up at 4am, or the guest saw a different time than the host intended. Compare the guest's screen, the confirmation, and the calendar event before you reschedule. A confirmation that says 4pm UTC and a calendar that says 6pm CET can both be the same moment.

What people actually report

Calendly's community troubleshooting guide, posted 23 October 2023, has 13,450 views and 23 replies. The usual shock is a confirmation that is not the hour the person thought they picked: noon becomes 1pm or 4pm. Calendly detects the timezone from the device and from synced calendars. Its example on that guide: 1pm Pacific is 4pm Eastern.

On the same thread, one host said reminder emails showed the host timezone and guests missed the meeting. Another host had a single invitee receive two calendar invites, one at 11am and another at 4pm, while only one appeared on the host calendar. A third host, leaving for a month in Kauai, two hours behind Pacific Time, could not find a way to shift only those dates without touching the rest of the schedule.

Lesley University's Microsoft Bookings note describes the same split. An Eastern Time user sees Eastern slots. A Pacific Time user sees Pacific slots. It also warns that a computer or a Microsoft 365 account can default to Pacific Time even when the person is somewhere else. The control on the Bookings page is the globe icon.

Why the same slot looks like two times

Calendly's help page, updated 13 October 2026, says Calendly detects the invitee's timezone and shows availability in their local time. The event then appears on the invitee's calendar in that calendar's timezone. If the calendar app cannot detect a timezone, the invitation can display UTC. Calendly says this is especially common for Hotmail, Yahoo, and AOL. Email confirmations still show the timezone that was on the booking page. Calendar invitations follow the receiving calendar instead.

A VPN is a frequent cause. The browser reports the exit-node city, not the city the person is sitting in. A rented laptop does the same thing. The guest then books a slot that is correct for the VPN and wrong for the meeting.

Daylight saving is the quiet version of the same bug. A nearby city is not a safe substitute if it changes clocks and yours does not. TimeTuna's docs say that before October 2026, Bogota, Lima, Mexico City, and Caracas were listed under New York, Chicago, or Santiago. Those zones change their clocks. Bogota, Lima, Mexico City, and Caracas do not. The documented fix is to pick the city's own name on the Schedule tab, even if the clock matches today.

In-person visits need the place, not the guest's browser

Cal.com's 26 June 2024 post on Lock Timezone uses a dentistry example. An overseas client books an in-person visit. Without the lock, the times follow the city the client is browsing from, not the city of the chair. Lock Timezone sits in the Advanced section of that event. It applies to that event only, not to every event on the account.

Calendly's help page gives the same advice for in-person events: lock the timezone to the event location. Each Calendly schedule is tied to one timezone. For travel, Calendly says to convert the destination's working hours into the schedule timezone and enter them as date-specific hours. Flipping the whole schedule early also shifts dates after the trip.

Put the city in the event title when the guest has to be physically there. A video call should follow the guest's clock. A chair, a studio, or a salon should follow the place.

What to check before you blame the tool

Host: open the booking page and confirm the saved timezone is the city you work in, not a nearby city with different daylight-saving rules. Then open Google Calendar or Outlook and confirm that calendar uses the same city. TimeTuna's docs note that Outlook in particular shows a converted time when the calendar timezone and the page timezone differ.

Guest: read the timezone label before choosing a slot. On Calendly it is the dropdown on the scheduling page. On Microsoft Bookings it is the globe icon. On TimeTuna it is the timezone selector next to the time slots. If the label names a VPN city, change it before booking.

After the book: compare three strings. The time the guest saw, the time in the confirmation, and the time on the calendar event. If two of them are the same moment written in different zones, nobody booked the wrong hour.

How TimeTuna handles the three clocks

TimeTuna stores weekly hours in the booking page timezone, set on the page editor under Schedule. The default grid is Monday to Friday, 9 to 5 in that timezone. Guests see slots in the timezone their browser reports, and they can override it with the selector next to the time slots. If the detected zone looks off, they pick their city and the times update. Hours set as 9 to 17 stay 9 to 17 in the chosen city year-round.

Confirmation emails show the time in the guest's timezone. TimeTuna's docs use this pair on purpose: if the email says 4pm UTC and the host calendar says 6pm CET, both are correct.

When the guest is far enough away that the clocks disagree, suggested times show the guest's local time and the host's local time on the same row. The availability docs give the example: a guest in Amsterdam looking at an Auckland host sees 12:00 AM alongside 10:00 AM for the host. Guests in the host's own timezone see no extra label. Guests never see the host's existing meetings.

If you travel, change the page timezone to the destination on arrival. Past bookings are unaffected. Future slots use the new local hours. You do not need a second booking page for the trip.