Timezones, done right
Cross-region scheduling, DST-correct payroll, and unambiguous booking times — engineered into the platform from the ground up.
Why timezones matter for staffing
A surgeon in Madrid books an operating-room slot at a hospital in Moscow. The start time has to be unambiguous to the second for both parties, survive daylight-saving changes on either side, and produce the correct number of paid hours on the nights clocks shift. Most systems treat time as a single offset and quietly get this wrong twice a year. This platform does not.
Every tenant, booking, and device timezone is a validated IANA identifier such as Europe/Brussels — never a raw, ambiguous offset.
- Validated against the IANA time-zone database at every boundary.
- Invalid or misspelled zones are rejected with a clear error before they reach your data.
- The zone database ships with the platform and updates predictably on both Windows and Linux hosts.
Booking start and end times, availabilities, and audit records are stored as absolute UTC instants — exact to the second for every party in every region.
- A shift created in Madrid and viewed from Moscow refers to the exact same instant in time.
- No drift when a country retroactively changes its daylight-saving rules.
- Clients render local wall-clock time themselves from the instant plus a zone.
Twice a year clocks shift. Instead of silently guessing, the platform applies a defined, tested policy.
- A wall-clock time that does not exist (spring forward) is rejected with a clear explanation.
- A wall-clock time that exists twice (fall back) defaults to the first occurrence.
- Wall-clock duration stays correct on transition nights — a 22:00–06:00 shift is 9 hours in autumn and 7 in spring.
Each booking carries an authoritative operating zone — the zone in which its wall-clock time is canonical for payroll, regulatory reports, and on-site staff.
- Defaults to the tenant timezone, with room to refine per department later.
- Payroll and compliance reports use this zone, never the viewer’s device.
- A device timezone drives display hints only — it never changes a stored time or a calculation.
How daylight-saving edge cases are resolved
Every daylight-saving zone has two ambiguous moments a year. The platform resolves both deterministically rather than surfacing an error to your operators.
When clocks jump forward, a wall-clock time such as 02:30 on 29 March 2026 in Europe/Brussels never happens. A booking at that time is rejected with a clear message, instead of being silently shifted to a different hour.
When clocks fall back, a time such as 02:30 on 25 October 2026 happens twice. The platform defaults to the first (pre-transition) occurrence; a client that needs the second sends an explicit UTC offset.
A clean, predictable API contract
The API speaks four precise time shapes. Absolute instants dominate the wire; clients format local time themselves, so the API never serves an ambiguous pre-rendered string.
| Concept | JSON shape | Example |
|---|---|---|
| Absolute instant | ISO-8601 in UTC (Z suffix) | 2026-04-27T22:00:00Z |
| Calendar date | ISO-8601 date | 1985-03-15 |
| Timezone | IANA identifier | Europe/Brussels |
| Zoned wall-clock | ISO-8601 with offset and zone | 2026-04-27T22:00:00+02:00[Europe/Brussels] |
Frequently asked questions
Yes. A resource in one country can be booked at a site in another; the time is stored as one absolute instant and rendered correctly in either zone.
It is rejected at the boundary with a clear error. Invalid IANA identifiers never enter your data.
The booking’s operating zone — by default your tenant timezone — so paid wall-clock hours are correct even on daylight-saving nights. The viewer’s device zone is never used for this.
Clients render local time from the absolute instant plus a zone. A device timezone can add a helpful “your local time” hint, but it never changes stored times or calculations.
Building cross-region scheduling?
IANA-validated zones, absolute instants, an explicit DST policy, and a per-booking operating zone are already built in. Let’s talk about onboarding your organisation.
Get started