How to Schedule Meetings Across Time Zones
A practical workflow for choosing a fair meeting time, handling daylight saving changes, and sharing an unambiguous international invitation.
Start with one exact meeting date
A statement such as “New York is five hours behind London” is only a shortcut for some dates. The difference can temporarily change because the two locations do not always begin and end daylight saving time on the same day. Start with the proposed calendar date, local time, and named IANA zone for the organizer. Then convert that one instant into every participant’s zone. This avoids treating today’s offset as a permanent rule and immediately reveals when a participant lands on the previous or next calendar day.
Use city or IANA zone names, not abbreviations
Short labels such as CST, IST, and BST can describe different regions. Ask for a city or an IANA identifier such as America/Chicago, Asia/Kolkata, or Europe/London. The identifier connects the meeting date to the region’s applicable civil-time rules. A numeric offset such as UTC+01:00 is useful when displaying the final result, but it does not by itself preserve the rules for a recurring meeting. Keep both the readable city name and the underlying IANA zone in the invitation.
Compare working hours and date rollover
Build a small table showing each participant’s local date, weekday, time, and UTC offset. Do not compare only the clock hour: 08:00 Tuesday for one person may be 23:00 Monday for another. Mark local public holidays and organization-specific non-working days separately from the time-zone calculation. If no option falls inside everyone’s normal working hours, make the inconvenience visible and rotate it across future meetings instead of repeatedly assigning it to one region.
Create the invitation from the organizer’s zone
Choose the zone that defines the meeting’s intended wall-clock time. For a one-time call, any correctly resolved zone can identify the instant. For a recurring office meeting, use the office or organizer’s named zone so the event remains at the intended local hour when that location changes clocks. Calendar formats such as iCalendar can carry time-zone identifiers and recurrence rules, but recipients should still see the local date and time in the written description as a human-readable check.
Recheck recurring meetings near clock changes
A weekly meeting at 09:00 New York time can move by one hour for London participants during weeks when the two regions are on different seasonal schedules. Review recurring series before the next known transition in every participating zone. If the desired rule is “always 14:00 UTC,” anchor it to UTC. If the desired rule is “always 09:00 at the New York office,” anchor it to America/New_York. Those are different scheduling promises and should not be mixed.
Send an unambiguous confirmation
The confirmation should include the organizer’s local date and time, the IANA zone, the UTC representation, and a short list of participant conversions. For example: “2026-11-05 09:00 America/New_York (14:00 UTC).” A UTC offset can be added for readability. Avoid writing only “9 AM EST,” because the date may actually fall under daylight time and the abbreviation may be interpreted differently. Include a converter link so recipients can inspect their own location before accepting.
Final scheduling checklist
Before sending, confirm the year, month, day, weekday, organizer zone, destination zones, and any date rollover. Check public holidays and local working-hour expectations. For a recurring series, decide whether the local organizer time or the UTC instant must stay fixed, then inspect the next daylight-saving transition. Recheck future high-impact meetings after governments announce time-rule changes. The goal is not merely to display several clocks; it is to document one instant in a way every participant can verify.
Frequently asked questions
Why can the difference between two cities change?
The cities may start or end daylight saving time on different dates, or only one may change clocks.
Should a recurring meeting be stored in UTC?
Use UTC when the instant must stay fixed. Retain a named local zone when the meeting must stay at the same local wall-clock time.
Is a UTC offset enough for an invitation?
It identifies the offset for that instant, but a named IANA zone better preserves regional rules for future or recurring dates.
What should I check before sending?
Verify the full date, weekday, local times, IANA zones, UTC offsets, date rollover, working hours, and holidays.
Primary references
These standards and official pages support the definitions and rules discussed above. Time-zone policies and published calendars can change, so consult the responsible authority for critical future dates.
- Reference IANA Time Zone Database theory
- Reference RFC 5545: Internet Calendaring and Scheduling