One-off online workshop — engineering and QA handoff
Scope: a 60-minute online event with international participants. Recurring, all-day and physical venue bookings are excluded.
Decision: before confirmation, resolve the organizer's local date/time and chosen event zone. After confirmation, the stored UTC instant is the commitment.
Fixture: 2026-10-15 15:00 Asia/Seoul, UTC+09:00 → 2026-10-15T06:00:00Z; end 07:00Z. New York starts Oct 15 at 02:00; Los Angeles starts Oct 14 at 23:00.
Inputs: date, time and event time zone are separate, visible fields. A browser zone is a suggestion requiring organizer confirmation. Language does not change time.
Validation: the server checks the supported zone and resolves candidate instants. Zero means a nonexistent time; two require an explicit choice with offset and a first/second-occurrence explanation. No silent correction or default first occurrence.
Confirmation: show event date/time, region, UTC offset, participant-local date/time and elapsed duration. Revalidate the inputs and zone rules on the server and compare the preview version. Changed results require a fresh confirmation.
Record: original local input, event zone, selected offset, confirmed UTC start/end, confirmation timestamp, time-zone database version, schedule version and change reason. Keep display values separate from the original record.
After confirmation: device-zone changes affect display only. A rules update may change the displayed wall-clock time but cannot silently move the confirmed UTC instant. Show the change notice alongside the current schedule.
Rescheduling: the organizer previews and confirms a separate change. Increment the schedule version and retain old values and the reason. Notifications link to the new version. Failed sends remain pending for delivery; they do not undo the committed schedule.
Owners: product defines the commitment and change policy; engineering owns server resolution, version conflicts and conversion; design owns both dates and error messages; operations owns recipients and failed sends; QA checks boundaries.
Checks: Korea/New York/LA display; unknown or missing zone; DST gap; DST overlap; explicit overlap choice; device or language change; stale preview; rule update; notification failure.
Before launch: agree supported zones, database-update ownership and notification-retry ownership. A failing boundary check blocks new confirmations until corrected; preserve stored instants of existing reservations.
Verification limit: numerical fixtures were round-tripped with Python zoneinfo. This is not an implemented or integration-tested booking/notification service.
Make the reconfirmation rule explicit: expire the previous preview if the original input, selected overlap occurrence or time-zone database version differs at confirmation. Even if only the database version changes and the resolved UTC instant is identical, show a fresh preview and require confirmation again.