A meeting scheduled "at 3 PM" means something completely different depending on which time zone you and the person you are meeting are each sitting in — and this ambiguity has caused countless missed calls, awkward middle-of-the-night dial-ins, and last-minute scrambles to figure out who got the conversion wrong. As remote work and international collaboration have become routine, time zone confusion has become one of the most common, entirely avoidable scheduling mistakes. This guide covers how to handle it reliably.
Why "3 PM" alone is meaningless across time zones
The moment two people in different time zones are involved, a time without an explicit zone attached is genuinely ambiguous — "let's meet at 3 PM" could mean 3 PM in your time zone, the other person's, or a third reference zone entirely, and each interpretation points to a completely different actual moment. This sounds obvious once stated, but it is exactly the kind of assumption that slips past people in a quick message or calendar invite, especially when both parties are used to their own local time and forget the other person is not. The fix is simple in principle — always specify the time zone explicitly — but it requires a deliberate habit, since defaulting to "just my local time" is the natural, unconscious behaviour.
The reliable way to convert a time
Rather than doing mental arithmetic with UTC offsets, which is easy to get wrong especially across zones with unusual half-hour or 45-minute offsets, use a dedicated converter that accounts for the current offset between the two specific zones, including any daylight saving adjustment currently in effect. The Time Zone Converter converts a specific time between any two zones directly, and the World Clock shows the current time in multiple zones at once, useful for quickly checking whether a proposed time falls in reasonable working hours for everyone involved before you even send the invite.
Why daylight saving makes this even trickier
Many countries observe daylight saving time, shifting their clocks forward or back by an hour at different points in the year — and crucially, different countries change their clocks on different dates, so the offset between two zones is not even constant throughout the year. A meeting time that was correctly converted in January can be an hour off by July if one of the two locations has since shifted for daylight saving while the other has not. This is precisely why "always use the same offset I calculated last time" is a dangerous shortcut — the correct offset between two specific zones can and does change at different points in the year, and a converter that accounts for the current date avoids this trap entirely.
Best practices for recurring cross-timezone meetings
For a meeting that repeats regularly, the most robust approach is to schedule it based on a fixed UTC time (or a specific participant's local time, explicitly noted) rather than trying to hold a fixed "local time" for every participant simultaneously, since local times relative to each other shift whenever any involved zone changes for daylight saving. Most modern calendar tools handle this reasonably well if events are created correctly with an explicit time zone attached, automatically adjusting the displayed local time for each participant as daylight saving shifts occur — but it is worth verifying this behaviour once with a test invite, since a poorly configured recurring event can silently drift by an hour after a daylight-saving transition without anyone noticing until someone shows up at the wrong time.
Communicating a time clearly in writing
When proposing a meeting time in a message or email rather than a calendar invite, state it in a format that leaves no room for ambiguity: include the time zone explicitly (using a widely understood reference like a major city or a standard abbreviation, since some abbreviations are ambiguous across regions), and where the audience spans several zones, consider listing the equivalent time in each relevant zone directly in the message rather than expecting everyone to convert it themselves. This small extra effort — writing out "3 PM IST / 5:30 AM EST / 10:30 AM GMT" instead of just "3 PM" — removes the single most common source of scheduling errors at essentially no cost.
Finding a fair meeting time across many zones
When participants span three or more zones with very different working hours — common for globally distributed teams — there is often no single time that falls in comfortable working hours for everyone, and the fairest approach is to rotate the inconvenient slot rather than always asking the same region to accommodate everyone else. A team split across, say, India, Europe and the US west coast will always have at least one group meeting either very early or very late; deliberately alternating which region bears that inconvenience from meeting to meeting, and being transparent about doing so, tends to sustain goodwill far better than an unspoken pattern where the same participants are repeatedly asked to join at an awkward hour. The World Clock makes it easy to check several candidate times at once against every participant's local hours before settling on one that everyone can accept.
A quick checklist before sending an invite
- Always state the time zone explicitly — never assume "my time" is understood by everyone.
- Double-check the conversion with a tool rather than mental arithmetic, especially for unusual offsets.
- For recurring meetings, verify the calendar tool correctly adjusts for daylight saving transitions.
- When writing to a multi-timezone group, list the time in each relevant zone directly rather than expecting manual conversion.
Key takeaways
- A time without an explicit time zone is genuinely ambiguous once more than one zone is involved.
- Use a dedicated converter rather than mental UTC-offset arithmetic, which is easy to get wrong.
- Daylight saving shifts change the offset between two zones at different points in the year — recheck rather than reuse an old conversion.
- State times explicitly with the zone attached, and list multiple zones directly for group communications.