The booking says 3 PM. In whose time zone?

Decide whose clock the booking refers to

Consider a fictional 60-minute online workshop with participants abroad. The request is simple: let the organizer select a date and time. But if their 3 PM becomes 3 PM on every participant’s device, people will join at different instants. First establish whether everyone is meant to attend the same event at the same instant.

For this case, the organizer explicitly chooses the event time zone; participants see that same instant in a zone they can change. Recurring classes, all-day events and physical venue bookings are outside the scope. A weekly local-time commitment or a shop’s opening hours needs a different policy.

Put the commitment in the product brief before drawing the picker. Once this workshop is confirmed, its stored instant stays fixed even if time-zone rules change. Moving the event requires a separate organizer confirmation. That decision prevents different screens from implementing different meanings of “the booked time.”

A date and a time are not enough input

An initial design might save the picker value and convert it on display. MDN explains the missing piece: a datetime-local input has no time zone. Interface language does not supply one either. Someone using Korean can still be in the United States.

A named zone identifies a region’s clock rules. Asia/Seoul refers to Seoul’s rules; UTC+09:00 means that a particular local time is nine hours ahead of UTC. A zone and an offset serve different purposes. Today’s offset alone is an unreliable basis for resolving a future local date.

Change the input specification to separate date, time and event zone. Offer supported named zones, with the browser’s zone only as a suggestion that the organizer must confirm. Document that changing language does not change the chosen zone. Keep this decision in both the input specification and its acceptance checks.

Resolve the input to exactly one instant

A valid date/time format is not enough to confirm a booking. Clock changes in some regions create local times that never occur or occur twice. The server must resolve the date against the selected zone’s rules. Passing the browser’s input validation does not prove the booking exists.

If there are no candidates, say that the time does not exist in the chosen region and ask for another time. Do not silently shift it. If there are two candidates, explain the first occurrence and the second occurrence after the clock moves back. Show both offsets and participant-local previews, then require an explicit choice.

After resolving one candidate, show the final review. On confirmation, the server must revalidate the input and rules and compare the preview version. If the input or resolution changed after the preview, show the new result and ask for confirmation again. An old preview cannot authorize a different instant.

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.

Use boundary values to check the design

A normal Seoul example makes most designs look correct. Check a normal time, a gap and an overlap separately. For this article, the values were resolved with Python zoneinfo, converted to UTC and round-tripped to the original region. Candidates representing the same UTC instant were deduplicated.

New York’s 2026-11-01 01:30 has two candidates: 05:30Z and 06:30Z. On 2026-03-08, 02:30 has no candidate that returns to the original local input. Record the time-zone database version used by the service. A library’s automatic correction is not evidence that a nonexistent local time is valid.

The selector below shows fixed design examples. It does not create reservations or send notifications. Use the values as fixtures against real server responses, and add relevant boundary dates when supporting additional regions.

Separate the confirmed record from display values

“Store UTC” alone is an incomplete handoff. Retain the original local input, event zone, selected offset, resolved instant and rule version so that someone can understand why this time was confirmed. Keep the original record separate from current display values.

On the participant screen, place the event reference and participant reference together: “Oct 15, 15:00 · Seoul / Your time: Oct 14, 23:00 · Los Angeles.” Do not omit the date. Allow a manual display-zone choice so a misconfigured device does not prevent checking the schedule.

For this example, 60 minutes means elapsed time. Add 60 minutes to the confirmed start instant and convert both endpoints for display. Do not subtract local clock digits across a clock change to calculate duration. If the dates differ, show both dates.

Ask AI for missing conditions before trusting conversions

A broad request to write a time-zone booking specification may stop at “store in UTC.” Supply the one-off event scope, the decision to preserve the confirmed instant, and the two dates that the screen must show. The prompt below is an unexecuted example, not a transcript.

If a proposed answer says only “convert to US time,” the region is missing. Specify New York and Los Angeles and ask how the duplicated local time is chosen. A useful follow-up example is: “Write labels distinguishing the two 01:30 occurrences and the server rejection condition when neither is selected.”

Accept an answer only when it agrees with the normal, gap and overlap fixtures, refuses nonexistent times and preserves the chosen post-confirmation policy. Verify numerical output against a time-zone library before putting it in a specification. Fluent wording is not evidence that a conversion is correct.

Example prompt: We are designing a one-off 60-minute online event with international participants. The organizer confirms the event zone, and the UTC instant stays fixed after confirmation. Find missing conditions between input and final review. Separate nonexistent times, duplicated times, device-zone changes and rule changes after preview. Give screen messages and server rejection conditions. Exclude recurring events.

Changing the schedule and delivering a notification are separate

An organizer reschedule changes the commitment. Show a new preview, obtain explicit confirmation and then increment the schedule version. Retain old and new values for operations, and send affected participants a notice linking to the latest schedule.

A failed notification must not revert a schedule already committed. Reservation details show the new version while failed deliveries await retry. Record delivery results per participant and schedule version to reduce duplicates. A sent notification is not proof that the participant read or accepted the change.

Rule updates require an impact check. This policy keeps the confirmed instant fixed, so local displays may change instead. Identify affected schedules and participants and explain the change. If the organizer wants to retain the old local clock time, that requires an explicit reschedule; a rules update is not organizer approval.

Give QA values, not just “the picker works”

Selecting a date and pressing Save will miss the difficult cases. Connect each input, selected zone, expected UTC instant and display date in one test. For rejected input, verify that nothing was committed. A blocked frontend does not help if a direct request still reaches the database.

The table is an acceptance plan for an implementation. This article verified conversion fixtures; reservation persistence, version conflicts and notification handling still need service integration tests. Do not give design review and integration acceptance the same completion label.

Adapt the time commitment before reusing the handoff

Use the handoff below, but do not start by replacing zone names. First decide what your service promises: a shared instant for an online event, or a local clock time tied to a physical venue. In the latter case, reconsider the rule-change policy rather than copying this one.

Product owns that scope and policy. Engineering adds supported zones, the database-update process and server outcomes. Design connects the two-date display and the overlap selector. QA compares the acceptance table against real responses. Operations needs named owners for rule updates and failed deliveries.

On first rollout, a boundary-test failure should stop new confirmations until corrected. Do not bulk overwrite existing confirmed instants to make the data look consistent. Revalidate new inputs after the fix and separately inspect any existing reservations that might be affected.

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.

Sources and example conditions

This is a fictional 60-minute online workshop. Public references support time-representation facts; the booking and change policies are design choices for this case. Numerical fixtures were round-tripped with Python zoneinfo, not tested in a live booking integration. AI prompts are unexecuted examples. English and Chinese localize the same Korean case.

MDN — datetime-local input

W3C Group Draft Note — Working with Time Zones

RFC 3339 — Date and Time on the Internet