# 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.

The days are the business's too. "Today" on the booking page's date picker is
the business's today, and the days it greys out are the ones already over at
the business — so a customer abroad late at night still sees the business's
current day, and can still book what is left of it.

## Reports and monthly totals

Days and months are the branch's too. "Today" on your dashboard, "this month"
and "last month" on its cards, the monthly bars in Reports, the revenue split and
the forecast all start and end at midnight on the branch's clock.

So a booking at 00:30 on the 1st counts in the month that has just begun, and
one at 23:30 on the last day counts in the month that is ending — wherever you
open the report from. The monthly revenue split pays out on the same boundaries
the calendar shows.

Money you record is filed under the day it arrived, as a date on the branch's
calendar, so collected totals follow the same months.

**Across all your branches**, the combined view uses your branches' clock when
they all keep the same time — an organisation whose branches are all in one
city sees its months end at that city's midnight. Branches in genuinely
different time zones are the exception; see the limits below.

## Setting it

The time zone is a branch-level setting. Each branch has its own, set when the
branch is created and changeable in
[Settings → Business profile](/docs/reference-business-profile#time-zone), or by
the owner in Settings → Branches.

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 — one hour apart, all year.

- 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.
- **"All branches" needs one clock, and branches on different clocks don't
  have one.** When every branch keeps the same time — all in one zone, or in
  zones that never differ, such as London and Dublin — the combined totals use
  that time. When branches genuinely keep different times, the combined totals
  split months at midnight Central European Time instead, so a booking in the
  first or last hours of a month can land in the neighbouring month there.
  Each branch's own view always uses its own clock.