Two Time Zones in Every Booking #
Each booking involves a host time zone, taken from the availability schedule, and an invitee time zone, detected from the browser. All internal timestamps are stored in UTC, and every displayed time is converted at render.
What the Invitee Sees #
The booking page shows a time zone selector above the calendar, preselected from the browser. Someone in Berlin viewing hours defined 09:00 to 17:00 India time sees the equivalent 05:30 to 13:30 window. Changing the selector re-renders slots instantly without losing form input already entered.
Daylight Saving #
Working hours are stored as wall-clock times in a named zone, not as fixed UTC offsets. A meeting set for 10:00 in a zone that observes daylight saving stays at 10:00 local time on both sides of the transition. The corresponding UTC time shifts, and MixCalendar recalculates it automatically. This is why choosing a named zone such as Europe/London matters more than the current offset.
Meetings That Cross a Transition #
When a booking is created before a daylight saving change and takes place after it, the confirmation email states the time in both the host and invitee zones with the zone abbreviation, which avoids the common one-hour misunderstanding.
Locking a Time Zone #
Event types can lock the displayed time zone so that every invitee sees a single fixed zone. This is used for events tied to a physical location, such as an in-person workshop, where showing a local conversion would be misleading.
Travel #
Travelling does not change your availability. Working hours stay anchored to the schedule’s time zone until you edit it. If you want a trip to shift your bookable hours, either edit the schedule’s zone for the duration or use date overrides for the specific dates.
