# Time zones — which clock everything uses

> Every booking time you see anywhere in Bookodile is in the business's own time zone, including your dashboard. What that means when you travel or run branches in different countries.

_Last verified: 2026-09-05. Source: https://bookodile.com/docs/time-zones_

**Every booking time renders in the business's time zone.** Your booking page,
your emails, and your own dashboard all use the shop's clock — not the clock of
the device you happen to be holding.

That is one rule with no exceptions, and it is worth knowing because the
alternative is worse than it sounds.

## Why it works this way

You read times off your dashboard to tell customers. "You're booked for ten
past two." If the dashboard used *your* device's clock, an owner in one country
looking at a branch in another would read out a time that does not exist for
either the customer or the staff member on duty.

So the branch's own clock is the only one used, and the time you see is the time
the person at that location will be standing there.

## What this means in practice

**If you travel**, your dashboard does not follow you. Open it from another
country and every booking still shows in the shop's local time. Nothing shifts
under you, and what you read out stays correct.

**If you run branches in different countries**, each branch shows its own local
times. Switching branches switches clocks. A 10:00 booking in the Dublin branch
reads 10:00 whether you look at it from Dublin or from Bratislava.

**Daylight saving is handled for you.** Times are stored as absolute instants
and rendered in the branch's zone, so the hour a clock change adds or removes
does not shift existing bookings.

## What the customer sees

Your booking page shows times in your business's zone, and tells the customer
when that differs from their own:

- **Same clock as yours** — a quiet one-line note. Most customers are local and
  a warning they do not need is a warning they learn to ignore.
- **A different clock** — a visible callout above the times, naming both zones,
  and their own local equivalent shown again on the confirmation step, where
  they are one tap from committing.

This compares actual clock offsets rather than zone names, so a customer in
Prague booking a shop in Bratislava is not warned about a difference that does
not exist.

## Setting it

The time zone is a branch-level setting. Each branch has its own, set when the
branch is created and changeable in its settings.

Get this right before you take bookings. Changing it later does not move
existing bookings — they were stored as real moments in time, so they keep
meaning the same moment, and their displayed time will shift to match the new
zone. That is correct behaviour and still surprising, so change it early or not
at all.

## Worked example

A studio in Dublin, an owner in Bratislava — two hours apart in summer.

- A customer in Dublin books 10:00. Their booking page shows 10:00 and warns
  them about nothing, because they share the studio's clock.
- The confirmation email says 10:00.
- The owner, in Bratislava, opens the calendar and sees the booking at **10:00**
  — the studio's time, not 11:00.
- The instructor in Dublin sees 10:00.

Everyone involved says the same number out loud.

## Limits

- **The zone belongs to the branch, not the business.** Two branches in one
  organisation can and often should differ.
- **Customers cannot choose a display zone.** They see the shop's times, with
  their own equivalent alongside when the two differ.
- **Changing a branch's zone re-renders existing bookings** in the new zone.
  The underlying moment does not move; the number on screen does.