BookodileBookodile
Browse all articlesβŒ„

Taking bookings

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 View as Markdown

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.
NextMoney β€” what Bookodile does and does not do