Synthetic booking table: Google Calendar event IDs and local times across clock changes

Invented bookings and how offsets were checked

Booking numbers and times are invented. The offsets and conversions were computed with a standard time-zone database routine for the 2026 dates shown, and the two clock-change rows were checked by converting each local time to UTC and back. The event IDs are an authored scheme, the letters bk followed by the booking number, which uses only characters Google allows. No calendar was written to; this is a specification for tests.

• Event IDs: bk000001 to bk000005.
• UK clocks go forward on 29 March 2026 and back on 25 October 2026.
• US clocks went forward on 8 March 2026.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

id        | local start             | zone              | dateTime to write         | shows in London staff calendar
bk000001  | 2026-03-28 09:00        | Europe/London     | 2026-03-28T09:00:00+00:00 | 09:00
bk000002  | 2026-03-30 09:00        | Europe/London     | 2026-03-30T09:00:00+01:00 | 09:00
bk000003  | 2026-03-30 10:00        | America/New_York  | 2026-03-30T10:00:00-04:00 | 15:00
bk000004  | 2026-03-29 01:30        | Europe/London     | DOES NOT EXIST            | reject or ask: clocks skip 01:00-02:00
bk000005  | 2026-10-25 01:30        | Europe/London     | AMBIGUOUS (+01:00 or +00:00) | needs a stored choice: first or second 01:30

Reading the table

Rows 1 and 2 are the same wall-clock time either side of the UK change, written with different offsets, which is why a booking must carry its zone and not only its time. Row 3 shows a New York booking appearing at 15:00 on a London calendar once both regions had changed. Row 4 is a time the local clock never shows. Row 5 happens twice, so a stored booking time alone cannot say which instant was meant.

• Rows 4 and 5 need a rule agreed in writing before any code.
• A booking form that only offers valid times avoids row 4 at the source.
• Each row is a test: the event the sync writes must match the expected column.

Identity cases to add

Run each booking's create twice and expect one event with its ID. Move bk000002 one hour later and expect the same ID with a new time. Cancel bk000003 and expect it gone. Send an ID containing a hyphen or a capital letter on a test calendar to see Google's refusal before production does. Whether a cancelled booking's ID can be reused is not stated on the pages read, so test it and record the result.

• Create, repeat, move, cancel are the four identity tests.
• A 409 duplicate response on the repeat should lead to an update, not an error.
• Keep the expected table next to the observed one.

What was and was not exercised, and the paid step

Only the offset arithmetic was checked. No Google API call, authorisation or calendar view was exercised, so nothing here shows a sync working. The Google Calendar outcome is priced from a fixed £445 as an untested test price, with payment after the agreed checks pass and you sign off. Send your own five bookings in this form and the zones involved, never real customer details.