How to Share Meeting Times Across Time Zones
A local time is useful when paired with a date and a clear time zone. Problems arise when an invitation says only “9 AM” or uses an ambiguous abbreviation. Check the date in a global time planner before sending it.
“9 AM EST” can be confusing in summer, when New York usually observes EDT instead. Give a calendar date and a named city or UTC reference so recipients can verify the intended moment.
Why an abbreviation may be unclear
The abbreviation "EST" (Eastern Standard Time) is itself ambiguous. During North American summer, the East Coast operates on "EDT" (Eastern Daylight Time), which is UTC-4 — not UTC-5. Many recipients, particularly those outside North America, use "EST" and "EDT" interchangeably without realizing they are one hour apart. Sending "9 AM EST" in July is a recipe for a one-hour discrepancy in a recipient's calendar.
Beyond abbreviation confusion, there is a structural problem: timezone offsets are not fixed relationships. They shift — and not all countries shift at the same time.
Check daylight-saving transitions by date
Countries change clocks on different dates, and some do not change them at all. The offset between two cities can therefore differ from the one you remember. Check the meeting date instead of reusing last month’s conversion.
Here is a concrete example. The standard time difference between New York and London is 5 hours (London ahead). In the spring gap between US and UK clock changes, New York and London can be four hours apart instead of the more familiar five. The exact dates vary by year. A recurring meeting should be anchored in a named time zone and checked after each transition.
The situation is further complicated by countries that do not observe DST at all. Japan, China, India, most of sub-Saharan Africa, and several other major business regions have fixed timezone offsets year-round. This means their relationship to New York or London shifts by one hour during every DST transition, even though they did not change their clocks.
Send a dated calendar invitation
A calendar invitation helps participants see the meeting in their own zone, provided the organizer selected the correct date and zone. For an important meeting, include the reference time in the message too.
Calendar applications can display an event in each participant’s local zone. Verify the meeting date, anchor zone, and recurrence rule, especially around daylight-saving transitions.
Plain text time proposals (in emails or chat messages) should always include UTC as a reference anchor: "3:00 PM Pacific Time (PT) / [UTC time for the meeting date]." UTC has no DST shifts, no abbreviation ambiguity, and no regional variants. A location’s UTC offset can vary by date, so use the meeting date when converting.
Frequently Asked Questions (FAQ)
What is the safest text format for proposing a time across multiple timezones? Always express the time in UTC alongside the local time: "10:00 AM in New York on [date] / [corresponding UTC time]." UTC is the universal reference point — it never changes for DST, has no regional variants, and is understood by every timezone converter and calendar application globally.
How do half-hour and quarter-hour offset timezones (like India's IST +5:30) complicate scheduling? UTC offsets are not always whole hours: India uses +5:30, and some other regions use half-hour or quarter-hour offsets. Check the named location and meeting date instead of assuming an integer offset.
My calendar shows the correct time, but the recipient says it showed the wrong time. What happened? Check the event’s date, anchor zone, recurrence settings, and each device’s time-zone settings. Share the intended UTC time for a critical meeting so participants can compare it with what their calendar shows.
Use a time converter for uncertain dates and send an invitation that names the intended zone. Ask participants to verify the local time when the meeting is important.
Loading comments...