How to Write a Meeting Invite That Works Across Time Zones

Published 12 July 2026 · 7 min read

A meeting invite is a small piece of communication that carries a lot of weight. Get it right and attendees show up on time, prepared, knowing exactly what they're walking into. Get it wrong and you have a team scattered across three continents, half of them confused about when the call is, and one person on the wrong day because of a midnight UTC boundary.

The mechanics of writing a good cross-timezone invite are straightforward. Here's everything that should go into one, and why each element matters.

The problem with a bare time in a calendar invite

The most common mistake in cross-timezone invites is specifying a time without specifying a time zone — or worse, specifying a time in the organiser's local zone with the assumption that everyone's calendar will auto-convert it.

Modern calendar apps (Google Calendar, Outlook, Apple Calendar) do handle time zone conversion automatically for events created in a named time zone — but only when the event is created correctly. If you send an invite and the recipient's calendar doesn't recognise the time zone encoding, or if you paste a time into a Slack message or email, no automatic conversion happens. They see "3pm" and assume their own local time. This is where missed calls happen.

A well-written invite removes any dependence on automatic conversion by being explicit in plain text. Every attendee should be able to read the invite description and know exactly when the meeting is in their local time, without having to calculate anything.

What to include in every cross-timezone invite

These five elements should be in every calendar invite that spans more than one time zone:

1. The UTC time and date. This is your anchor. Write it as 24-hour time: "14:00 UTC on Wednesday 23 July." UTC never changes with DST, so it's the most durable reference point.
2. The local time for every attendee city. List each city's local equivalent in the invite description. Not just the organiser's time zone — everyone's. "14:00 UTC = 10:00 New York (EDT) = 15:00 London (BST) = 22:00 Singapore (SGT)." This takes 30 seconds to generate with a good time zone tool and saves attendees from doing the mental arithmetic themselves.
3. The date in each time zone. If the UTC time is late evening, it may be the following calendar day in Asia-Pacific. State the date explicitly for any time zone where the day might differ: "22:00 Singapore (SGT), which is Wednesday evening Singapore time."
4. A link to verify. A shareable URL from a time zone planner that encodes the cities and selected time means anyone can click through to confirm or double-check their local equivalent. Useful for complex multi-city meetings.
5. The time zone the calendar event itself is set in. If you're using Google Calendar or Outlook, set the event in a named IANA time zone (e.g., "America/New_York" or "Europe/London"), not as a raw UTC offset. Named time zones adjust automatically for DST; raw offsets don't. This matters for recurring meetings.

A reusable template for cross-timezone invites

Here's a template you can adapt for any multi-timezone meeting:

The emoji flags are optional but make the list visually scannable. The important parts are the UTC anchor, the explicit local times for each location, and the UTC offsets in brackets so people can verify.

Calendar apps and automatic time zone handling

When you create an event in Google Calendar, you choose the time zone the event is set in. If you choose "London (Europe/London)," the event will display as 15:00 BST for London attendees in summer and 15:00 GMT in winter — the calendar adjusts automatically when DST transitions happen. This is correct behaviour and is why IANA named time zones (like "America/New_York" or "Australia/Sydney") are far more reliable than raw UTC offsets (like "UTC−5").

A raw UTC offset of "UTC−5" doesn't know whether you mean New York in winter or New York in summer (when it's actually UTC−4). An IANA named time zone knows both, because the database includes every DST rule for every region. Always set your calendar events using named time zones when the option is available.

Outlook works the same way. When you add an attendee in a different time zone, Outlook will show you the event time in their local zone when scheduling — but only if their calendar's time zone is set correctly in their account settings. For external attendees, you can't rely on this, which is why the plain-text local time list in the invite description is always worth including.

Recurring meetings need extra care

Recurring meetings are where time zone errors accumulate. A weekly meeting set up correctly in January may appear to shift by one hour for some attendees in March when DST transitions happen, particularly if the meeting was set up with a raw UTC offset rather than a named time zone.

After each major DST transition — US transitions in mid-March and early November, European transitions in late March and late October — check your standing recurring meetings. Open each one, verify that the listed local times are still correct for all attendees, and update the invite description if they've shifted. This takes five minutes and prevents weeks of silent confusion.

Generating the local time list automatically

Manually calculating local times for five cities is tedious. A time zone planner takes care of it: you add your cities, select the date and drag the time selector to the meeting time, and it shows you every city's local equivalent simultaneously. The "Copy summary" function then generates a plain-text list of local times, ready to paste into the invite description.

Calendar apps handle time zone conversion differently, and behaviour may vary across platforms and versions. Always confirm local times with attendees in different regions for high-stakes meetings, particularly those near DST transition dates.