Plan a meeting across daylight-saving changes
Avoid treating city timezones as fixed UTC offsets and use a concrete date when comparing future meeting times.
A city timezone is not a fixed offset
A named timezone such as America/New_York includes rules that can change with the date. UTC−5 is only an offset. Two regions may switch daylight-saving time on different weekends, making their time difference temporarily change. The existing world clock compares the current instant; it does not calculate a future meeting date. Use a calendar with named timezone support for scheduling.
Record date, time and timezone together
Write a complete meeting date and city timezone, then check the corresponding local date for every participant. “9 tomorrow” is ambiguous when readers are in different regions or see the message later. A late-night meeting can be on the following calendar day elsewhere. Prefer a calendar invitation that preserves the event’s timezone and lets each recipient see their local rendering.
Watch the transition hour
When clocks move forward, some local times do not occur. When clocks move backward, an hour can repeat. Avoid scheduling in a transition interval unless the application lets you explicitly resolve the ambiguity. For a recurring meeting, decide whether the organizer’s local time or a fixed UTC time should stay constant. Those choices produce different behaviour for participants after seasonal changes.
Check the invite before sending
Preview the first occurrence and another occurrence after the next timezone change. Confirm duration, local date and the organizer’s chosen timezone. The current-time tool is useful for a call now, while the date countdown shows a target in your own browser timezone. Neither replaces the calendar invitation. Government rule changes and outdated device timezone data can still require a final check close to the event.