How do you find a good meeting time across time zones?
Find a good meeting time by working from the participants outward: list everyone's time zone, find the hours when their working days overlap, fix the chosen moment to Coordinated Universal Time (UTC), and convert that single instant back to each person's local clock to confirm it. Anchoring to one neutral reference and converting once is what keeps the arithmetic honest — the alternative, adding and subtracting offsets between every pair of cities, compounds a mistake at each hop.1
- List every participant's time zone. Write down each attendee's location or time-zone identifier — New York, London, Kolkata — rather than a bare abbreviation, because abbreviations such as CST and IST each name more than one zone.
- Find the overlapping working-hours window. Lay each participant's normal working day, say 09:00 to 17:00 local, on one shared timeline and look for the hours when everyone is simultaneously at work; that intersection is the set of acceptable start times.
- Anchor the chosen time in UTC. Convert the slot you pick into Coordinated Universal Time and treat that single UTC instant as the meeting's canonical time, because UTC never changes for daylight saving and every local clock is defined as an offset from it.
- Confirm the local time for each participant. Convert the UTC instant back into each person's local clock and check that it still lands inside their working hours and on the expected calendar day, since the conversion can cross midnight into the day before or after.
- Check for a daylight-saving change near the date. Verify that none of the participants' regions change their clocks between today and the meeting date; if one does, its offset from UTC — and therefore its local meeting time — will differ from what today's conversion shows.
The conversion itself is mechanical, and a tool will do it without error: the meeting planner lays every participant's working hours on one grid and highlights the columns where they overlap, while the time-zone converter translates a single moment between two zones and the world clock shows everyone's current local time at a glance. The method above is what those tools encode; knowing it is what lets you sanity-check their output and reason about the one case they cannot fully resolve for you — a clock change between now and the meeting.
Why anchor the meeting to UTC?
Anchor the meeting to UTC because it is the one reference clock that does not move. Coordinated Universal Time is the international civil time standard, and every civil time zone is defined as a fixed offset from it — India is UTC+05:30, the United States Eastern coast is UTC−05:00 in winter, and so on.1 Pinning the meeting to a single UTC instant gives every participant's calendar one unambiguous moment to convert from, so two people in different cities are reasoning about the same point in time rather than two clock readings they each have to translate.
This is also how computers store the moment. The standard format for timestamps exchanged on the internet records the local time together with a numeric offset from UTC — for example 2026-09-14T15:00:00+01:00 — so that the underlying instant is recoverable regardless of which zone reads it.4 A calendar invite built this way will render the correct local time on every attendee's device, including for someone whose region sits on a half-hour offset or is about to change its clocks. The guidance that a time should carry an explicit offset rather than a bare abbreviation is the same reason the tz database that powers most software warns that "these abbreviations are ambiguous in practice."5
How does daylight saving time break a scheduled meeting?
Daylight saving time breaks a scheduled meeting because it moves a region's offset from UTC by an hour, and it does so on a date that may fall between when you schedule and when you meet. During its summer-time period a region runs its clocks one hour ahead of its winter offset; in the United States the change is at 2 a.m. on the second Sunday of March and back on the first Sunday of November, while the European Union and the United Kingdom switch on the last Sunday of March and the last Sunday of October.23 An offset you read off a converter today is only correct for today.
Two consequences follow for scheduling. First, because the regions change on different Sundays, the usual gap between, say, New York and London is briefly an hour off its normal value — for the two to three weeks each spring when North America has sprung forward but Europe has not, a call set "as usual" lands an hour adrift.23 Second, a recurring meeting that was comfortable in one season can drift into someone's evening after a changeover, because the two ends of the call do not necessarily move together. The fix is the final step of the method: before confirming, check whether any participant's region changes its clocks between now and the date, and re-convert against the date itself rather than today. The companion article on when the clocks change lists the exact dates, and the daylight saving time page covers which regions observe it at all.
What is good etiquette for scheduling across time zones?
Etiquette across time zones comes down to spreading the inconvenience fairly and removing ambiguity from the invite — three habits cover most of it:
- Rotate the awkward slot. When an overlap only exists at the edges of someone's working day, alternate which group takes the early-morning or late-evening call rather than fixing the cost on the same people every time.
- Label every time with an explicit zone or offset. Write "15:00 UTC" or "10:00 New York (UTC−4)", not "3 PM EST"; abbreviations are genuinely ambiguous — the tz database notes that "IST" can mean India, Ireland, or Israel and "CST" means one thing in North America and another in China — so a city name or a numeric offset removes the doubt.54
- Prefer asynchronous when no overlap exists. Once participants are spread far enough that no slot sits inside everyone's working hours, a live meeting forces someone out of theirs; a written update that each person reads in their own working day is usually the better trade.
Frequently asked questions
What is the best time to schedule a meeting across time zones?
The best slot is the one that falls inside every participant's normal working hours at the same instant; anchor it to UTC and convert once for each person to confirm. When the zones are far enough apart that no working-hours window overlaps, rotate who takes the inconvenient hour or move the update to an asynchronous channel.1
How do I account for daylight saving time when scheduling?
Check whether any participant's region changes its clocks between the day you schedule and the day you meet; if it does, that region's offset from UTC shifts by an hour, so re-confirm the local time against the meeting date rather than today.2
Should I send a calendar invite in UTC or local time?
Send it anchored to a single instant and let each attendee's calendar render it in their own zone. A well-formed invite stores the moment with a numeric UTC offset, so every client shows the correct local time — including across a daylight-saving change.4
What if there is no overlapping working-hours window?
When participants span roughly twelve hours or more, no single slot sits inside everyone's working day. Rotate which group takes the early or late call so the cost is shared, or replace the live meeting with an asynchronous written update that each person reads in their own working hours.
Why not just use time zone abbreviations like EST or IST?
Abbreviations are ambiguous: "IST" can mean India, Ireland, or Israel time, and "CST" means one thing in North America and another in China.5 A label built from a city name or a numeric UTC offset names exactly one moment, which is why timestamp standards use offsets rather than abbreviations.4
Footnotes
- 1. Recommendation ITU-R TF.460-6: Standard-frequency and time-signal emissions , International Telecommunication Union (2002) — accessed 2026-06-07.
- 2. Daylight Saving Time (DST) , National Institute of Standards and Technology, Time and Frequency Division — accessed 2026-06-07.
- 3. Directive 2000/84/EC of the European Parliament and of the Council on summer-time arrangements , European Parliament and Council of the European Union, OJ L 31, 2.2.2001 (2001) — accessed 2026-06-07.
- 4. RFC 3339: Date and Time on the Internet: Timestamps , Internet Engineering Task Force (2002) — accessed 2026-06-07.
- 5. Theory and pragmatics of the tz code and data , IANA Time Zone Database — accessed 2026-06-07.