What happens to bookings when clocks change?

Two days a year are not 24 hours long

Where the clocks change, one night in spring loses an hour and one night in autumn gains one. In Zurich in 2026, 02:00 on 29 March became 03:00, and at 03:00 on 25 October the clocks go back to 02:00.

A diary that keeps appointments as times on a wall clock goes wrong on both days, and quietly on every other:

• In spring, 02:30 never happens. A booking for it is a booking for a time nobody can arrive at.
• In autumn, 02:30 happens twice, an hour apart, and "02:30" on its own does not say which.
• Every day, "10:00" names a different moment for somebody whose computer is set to another timezone.

Store instants, show the business's clock

An instant is a moment that means the same thing everywhere, written with its offset: 2026-10-25T09:00:00+01:00. Store instants, compare instants, and turn one into a time on a wall clock only to show it, on the business's own timezone.

BackendFree converts once, on the server:

• Opening hours stay wall clock. A business says it opens at 09:00, on its own clock, and that stays true on both days of the year when the offset moves.
• Free times are worked out on that clock, so they sit on the business's grid of times, and only then become instants.
• Every time sent or accepted is an instant. A time without an offset is refused rather than guessed at, since the browser's clock, the server's and the business's are three different answers.

The two mornings

In spring, no time is offered inside the hour that never happens, because nobody could arrive then.

In autumn, a time inside the hour that happens twice is offered as the two moments it is, each with its own offset, and the diary decides whether either is free. Opening hours that span the repeated hour cover both passes of it, so a shift from 01:00 to 04:00 that night is four hours long.

Showing a time

The zone comes with the free times, so a page never has to guess it:

import { localTime } from '@backendfree/bookings';

const { slots, timezone } = await bookings.availability({ service, from: '2026-10-25' });

localTime(slots[0].start, timezone);   // on the business's clock

Keep the zone, never a fixed offset. Europe/Zurich is one hour ahead of UTC in winter and two in summer, so an offset that was right on the day somebody booked can be wrong for the appointment.

Somebody booking a Zurich haircut from a laptop set to New York sees nine in the morning, the time they have to be there. The confirmation email gives the same time on the business's clock, and its calendar file carries the instant, so their calendar puts it in the right place wherever they are.

Times and timezones has the details for developers, and Bookings the rest of the diary.