Start a time zone conversion with one unambiguous instant, then display that instant in each participant's named zone. Include the local date and UTC offset beside the time. Those fields resolve the uncertainty that a clock-only answer leaves behind.
Use a dated instant as the source
For this example, the source is 2026-11-01T05:30:00Z. The final Z identifies UTC. The display zones are America/New_York and America/Los_Angeles. These are the only named zones supported by this example; adding more requires checking their rules and testing the results.
NIST lists November 1 as the 2026 end of daylight saving time in participating US locations. At the local transition, clocks return from 2 a.m. to 1 a.m., repeating an hour. The transition is defined in local time, so the two cities do not change at the same UTC instant. NIST's daylight saving time rules
Keep these three original comparison rows together:
| Source instant in UTC | New York local date and time | Los Angeles local date and time |
|---|---|---|
| November 1, 2026, 05:30 | November 1, 2026, 01:30, UTC−04:00 | October 31, 2026, 22:30, UTC−07:00 |
| November 1, 2026, 06:30 | November 1, 2026, 01:30, UTC−05:00 | October 31, 2026, 23:30, UTC−07:00 |
| November 2, 2026, 05:30 | November 2, 2026, 00:30, UTC−05:00 | November 1, 2026, 21:30, UTC−08:00 |
The rows use the cities' published 2026 transition and offset records and were independently checked with Windows TimeZoneInfo. They are demonstration cases, not actual meeting bookings. New York's zone record, Los Angeles's zone record.
In the first two rows, New York's clock reads 01:30 both times. UTC−04:00 identifies the earlier occurrence; UTC−05:00 identifies the later one. Los Angeles is still on the previous calendar date in both rows. In the second row, subtracting a fixed three hours from the New York wall clock would give the wrong Los Angeles clock time. By the third row, both cities have changed offsets and the usual three-hour difference is back.
Ask for the missing choice before converting
If your input is simply “New York, November 1, 2026, 01:30,” ask: “Do you mean the earlier occurrence at UTC−04:00 or the later occurrence at UTC−05:00?” Do not choose one silently.
For the earlier occurrence, the source can be written 2026-11-01T01:30:00-04:00, equivalent to 2026-11-01T05:30:00Z. For the later occurrence, use 2026-11-01T01:30:00-05:00, equivalent to 2026-11-01T06:30:00Z. An explicit offset identifies the instant; when the input also claims a named zone, check that the offset agrees with that zone on that date.
A missing date, blank input, or invalid timestamp should produce a request for correction. A blank field should not turn into “now.” If a local time does not exist during a forward clock change, ask for a valid time rather than moving the meeting automatically. Limit the converter to the input formats and zones it actually supports.
Design the result around a stable source
Put the exact source above the outputs. Each output needs the named zone, full local date, time, and offset. Reordering the two display zones must leave the UTC source unchanged. Selecting a different sample changes the source; switching display order does not.
Use the local HTML example to compare the two repeated-hour cases and their full dated results. The rule source, supported zones, and testing date should accompany the example; a correct 2026 sample does not prove every historical or future conversion.
Copy this prompt for a conversion review sheet
Create a US English review sheet for a date-aware time zone converter. Return the explanation, a complete result table, and a proposed local interaction specification. Do not book or send a meeting.
Support only America/New_York and America/Los_Angeles initially. Use these fixed demonstration inputs and expected results:
1. 2026-11-01T05:30:00Z: New York 2026-11-01 01:30 UTC-04:00; Los Angeles 2026-10-31 22:30 UTC-07:00.
2. 2026-11-01T06:30:00Z: New York 2026-11-01 01:30 UTC-05:00; Los Angeles 2026-10-31 23:30 UTC-07:00.
3. 2026-11-02T05:30:00Z: New York 2026-11-02 00:30 UTC-05:00; Los Angeles 2026-11-01 21:30 UTC-08:00.
Show the exact UTC instant above the full dated outputs. Explain why New York 01:30 occurs twice and why a fixed three-hour subtraction fails in sample2. Preserve source identity when display zones are reordered.
For unqualified New York 2026-11-01 01:30, request earlier UTC-04:00 versus later UTC-05:00. Reject blank, missing-date, malformed and unsupported inputs without inventing a time. Explain that nonexistent local times need correction. Check any claimed named-zone/offset combination against date-specific rules.
Specify accessible sample selection, visible source/result labels and a complete text equivalent. Record supported formats/zones and require actual rule-data and interaction testing before use. Do not claim the proposed controls have been tested or that all world zones are covered. Keep scheduling records in the actual calendar workflow.
Check the conversion together in NOS
NOS can save and render prepared HTML so colleagues can inspect the UTC source beside the local dates and offsets. Keep the meeting itself in your calendar workflow. Before transferring a time, have the organizer identify the intended occurrence and compare both cities' full dated results.
Finish with one agreed UTC instant and its complete local representations, so nobody has to guess which repeated hour the invitation means.