Design prompt: calendar and booking

At the studio	In the design
the diary writes each appointment as one moment with the studio's city beside it; the guest artist's phone shows it in her home city's time	instant plus zone, each viewer's clock (steps 2–3)
the Saturday walk-in session is written as 12:00 in the studio's city every week, not as last Saturday's plus seven days	a series is a wall time (step 5)
the free slots posted on the studio's page may be gone when a client reads them	availability is a snapshot (step 7)
a deposit request holds a slot for a set time, and still holds it while the client's transfer is on its way; only the front desk writes a name in the book, never two in one slot	a hold extended while paying; one conditional write (steps 8–10)

In real terms: a booking UI shows moments the server owns, on clocks it does not.

Breaks down when: the front desk can message a client to agree a swap; a 409 only tells the second page to pick again.

Contrasting case: a single-office meeting room app: one zone, one clock, 09:00 is enough.

4.1 ExamHall EXH-3480 → MR !3780: the admin's board in the week of two clock changes

The pilot stored each session as a local string with no zone, and every browser read it in its own zone (EXH-3480). MR !3780 stores the instant with the centre's zone (steps 2–4).

4.1 model: weekdays Fri 23 Oct to Fri 30 Oct 2026 (6) · Leipzig sessions 09:00, Cairo sessions 10:00 · the Berlin admin sees both centres, a Cairo candidate books Leipzig · Intl (tz data of this Node), tz 2026c
4.1 EXH-3480 pilot: Cairo candidate's Leipzig sessions at the wrong instant, 23 Oct 1 h early, 26 Oct 2 h early, 27 Oct 2 h early, 28 Oct 2 h early, 29 Oct 2 h early, 30 Oct 1 h early
4.1 EXH-3480 pilot: Berlin admin's Cairo sessions at the wrong instant, 23 Oct 1 h late, 26 Oct 2 h late, 27 Oct 2 h late, 28 Oct 2 h late, 29 Oct 2 h late, 30 Oct 1 h late
4.1 EXH-3480 pilot: 12 of 18 views at the wrong instant
4.1 MR !3780: 0 of 18 views at the wrong instant · the admin's board on Mon 26 Oct: Leipzig 09:00 (her 09:00), Cairo 10:00 (her 08:00)

A string read in another zone names another moment: the Berlin admin's Cairo sessions moved by one hour, then two, then one (step 4).

4.2 Proof domain, streaming: a weekly New York show seen from Berlin and Cairo

A streaming service's talk show goes live at 20:00 in New York every Sunday; its schedule keeps that wall time with America/New_York (step 5).

4.2 model: a talk show live at 20:00 in New York every Sunday, kept as that wall time with America/New_York
4.2 Sun 18 Oct: New York 20:00 · Berlin Mon 02:00 · Cairo Mon 03:00
4.2 Sun 25 Oct: New York 20:00 · Berlin Mon 01:00 · Cairo Mon 03:00
4.2 Sun 1 Nov: New York 20:00 · Berlin Mon 02:00 · Cairo Mon 03:00
4.2 Sun 8 Nov: New York 20:00 · Berlin Mon 02:00 · Cairo Mon 03:00

Three zones, three change dates: New York leaves summer time on 1 November, a week after Berlin, so Berlin's viewers see the show at 02:00, 01:00, then 02:00 again.

4.3 The board for "Design the frontend of a booking calendar for test centres across the EU" (worked, not executed)

Typical question	Steps that answer it	Mechanism owner
"How do you render 09:00 in Cairo for a Berlin admin during a DST change?"	2–4	this lesson; timeZone in Intl: fsd-i18n-architecture
"A slot is shown free but was just taken. What does the user see?"	7, 8	this lesson; the problem-details body: fsd-api-contract-frontend
"The candidate pays in the last seconds of the hold. Then what?"	9, 10	this lesson; the countdown's clock: fsd-clock-sync-timers