Schedule a Meeting Across Daylight-Saving Changes

Choose city mode for civil-time rules

Use named zones such as America/New_York and Europe/London. Fixed-offset mode is useful when an offset is deliberately specified, but a fixed UTC−5 label is not equivalent to New York throughout the year. The converter depends on the runtime’s installed time-zone data.

Compare two dates instead of assuming one gap

At 09:00 in New York on January 15, 2026, the offset is UTC−5; London is UTC+0, so the meeting is 14:00 in London. On March 15, New York is UTC−4 while London has not yet begun its summer offset, so the same New York clock time is 13:00 in London. A recurring meeting can shift during mismatched transition weeks.

Reject local times that never occur

In New York on March 8, 2026, the spring transition skips the local hour containing 02:30. That wall-clock entry is nonexistent. Rejecting it avoids silently moving the meeting to an unintended instant. Choose an actual time before or after the transition and confirm the destination date.

Resolve local times that occur twice

On November 1, 2026, 01:30 in New York occurs twice. The earlier occurrence is 05:30 UTC and the later one 06:30 UTC. Use reject mode to expose the ambiguity, or choose earlier/later deliberately. Sending only “01:30 New York” without that choice leaves the instant unspecified.

Store the instant and display the zone

Once resolved, a UTC timestamp identifies the instant. Keep the intended named zone with the invitation so each viewer can see the local representation and future recurrences can use civil-time rules. A fixed one-hour duration and a move to the same wall-clock time tomorrow can span different elapsed durations across a transition.

Compare two transition weeks with a consistent source time

At 09:00 in America/New_York on March 22, 2026, New York uses UTC−4 while Europe/London still uses UTC+0. The London time is therefore 13:00. One week later, March 29, London uses UTC+1, making the same New York source clock time 14:00 in London. A saved five-hour difference would give the wrong answer for the earlier date even though the city names are unchanged.

In autumn the mismatch appears in the opposite transition sequence. On October 25, 2026, London has returned to UTC+0 while New York still uses UTC−4, so 09:00 New York is 13:00 London. On November 1 at 09:00, New York has returned to UTC−5 and the result is 14:00 London. These examples are date-specific calculations under the runtime’s zone rules, not a promise that future legislation preserves the pattern.

Verify the destination calendar date as well as its clock

For July 15, 2026 at 23:30 in New York, UTC is July 16 at 03:30. Tokyo uses UTC+9, so the destination is July 16 at 12:30. Reporting only 12:30 omits the next-day change. City mode returns the target date and a day offset; keep both with the clock display. The source date field describes the source city’s local date rather than an already converted UTC date.

A reverse direction can move into the preceding day. At 09:00 in Sydney on January 15, 2026, its UTC+11 offset gives January 14 at 22:00 UTC. Los Angeles uses UTC−8, giving January 14 at 14:00. The source and destination therefore have different calendar dates even though the conversion is an ordinary meeting time, not a midnight edge case.

Do not assume every repeated interval lasts one hour

Australia/Lord_Howe supplies a half-hour backward transition example. On April 5, 2026, its local 01:45 can identify two instants: the earlier occurrence is April 4 at 14:45 UTC, and the later one April 4 at 15:15 UTC. Their separation is thirty minutes. The converter discovers the actual offsets around the date instead of adding a universal one-hour correction to every repeated clock label.

Choose reject mode to surface ambiguity before selecting an occurrence. Earlier and later apply only when that wall-clock label actually exists twice. They do not manufacture an instant for a skipped spring time or a completely skipped civil date. If the entry is nonexistent, pick an actual source time and recheck its destination. A valid clock numeral alone does not prove that the corresponding local instant exists in the chosen city.

Store enough information to explain a recurrence choice

For a resolved meeting, retain the source local date, source clock, source IANA zone, any ambiguity choice, destination zone and UTC instant. These fields distinguish a meeting held at one fixed instant from a recurrence intended to remain at the same local time. The converter resolves one date at a time; it does not choose which city’s wall-clock preference a recurring invitation should preserve.

Both source and target dates must stay within the supported 1970–9999 range. Runtime zone data and future rule changes remain dependencies, and leap-second clock labels are outside the minute-input form. Fixed mode remains appropriate for deliberately stated constant offsets but does not infer civil-time rules. Before sending an invitation near a transition, verify a neighboring date and the actual destination date rather than copying a remembered seasonal offset.