Use a dated example
For 15 January 2026, 09:00 in Europe/London corresponds to 18:00 in both Asia/Seoul and Asia/Tokyo. For 15 July 2026, 09:00 in London corresponds to 17:00 in both cities under the browser's time-zone rules.
Seoul and Tokyo share UTC+09:00 in these examples. An earlier version of this guide incorrectly gave different times for them. Recalculate for the actual event date rather than copying a seasonal offset.
Enter the event in its source zone
In your calendar, set the event’s source city time zone and the local date and time written on the invitation. Check the displayed date in each destination city, especially when the event crosses midnight.
Use identifiers such as Europe/London or America/New_York rather than CST, which is ambiguous. The browser supplies time-zone data; keep the browser and operating system updated when rules change.
Handle skipped and repeated times
Some clock changes skip local times; others repeat an hour. If an event falls during a clock change, ask the organizer to confirm a valid time and the intended UTC offset.
A local time without an offset is not enough to identify an occurrence in a repeated hour. Include an unambiguous instant in the invitation and verify how your calendar handles it.
Share the decision, not just an hour
Share a calendar invitation containing the date and source time zone. Include any next-day result in your meeting message. A screenshot of a current world clock is not a dated invitation.
For recurring meetings, check dates on both sides of seasonal transitions. If no convenient overlap exists, rotate the inconvenience or use an asynchronous update. Star the team’s cities in World Clock for quick checks of the current workday.