Scheduling a meeting across time zones sounds like a simple arithmetic problem — add or subtract a few hours — but it's one of the most common sources of missed calls and confused invitations in remote and international work. The math itself isn't hard; what makes it error-prone is that the "few hours" keeps changing depending on the date, the country, and who you ask.
Why time zone math goes wrong
Most scheduling mistakes come down to a handful of recurring traps rather than genuine complexity.
Daylight saving time mismatches
Many countries shift their clocks forward or back seasonally, but they don't all do it on the same date. Europe and the United States both observe daylight saving time, but their transition dates in spring and autumn don't line up — Europe generally shifts about a week or two after the US in spring, and about a week before it in autumn. For roughly two to three weeks each spring and autumn, the usual offset between, say, New York and London shifts by an hour compared to the rest of the year. A meeting that was "9am their time, 2pm mine" for months can suddenly be off by an hour during these windows if you don't check.
Half-hour and quarter-hour offsets
Most time zones sit at whole-hour offsets from UTC, but a few don't. India (UTC+5:30), Iran (UTC+3:30), and parts of Australia and the Pacific sit on half-hour or even 45-minute offsets. Someone doing quick mental math based on "the usual" whole-hour difference will consistently land 30 minutes off when one side of the call is in one of these countries.
Ambiguous phrasing
"Let's talk at 3pm my time" is a common phrase and a common source of error, because it puts the burden of conversion on the other person, who may convert it wrong, forget which direction to shift, or apply the wrong current offset if daylight saving recently changed.
Best practices for avoiding mistakes
- State a timezone-anchored time, not a personal one. "14:00 CET" or "9:00 EST" is unambiguous; "my time" or "your time" is not.
- Use UTC as a shared reference for anything involving more than two parties, or any recurring meeting spanning multiple regions. UTC doesn't observe daylight saving, so it's a fixed point everyone can convert from consistently.
- Name the city, not just the abbreviation, when there's any risk of confusion — "CST" alone is ambiguous between US Central Time and China Standard Time, for example.
- Double-check during DST transition windows. If a meeting is scheduled near the edges of March/April or October/November, confirm the offset again close to the date rather than trusting a calendar invite created weeks earlier.
- Let calendar tools do the timezone conversion rather than doing it by hand, since most calendar software converts a UTC-anchored event correctly for each recipient's local settings automatically.
A worked example
Suppose a team needs to schedule a call between colleagues in London, New York, and Mumbai, outside of any DST transition window.
| City | Typical offset from UTC | Local time if UTC is 14:00 |
|---|---|---|
| London | UTC+0 (or +1 in summer) | 14:00 (or 15:00 in summer) |
| New York | UTC-5 (or -4 in summer) | 09:00 (or 10:00 in summer) |
| Mumbai | UTC+5:30 | 19:30 |
Anchoring the invite to "14:00 UTC" and letting each participant convert it locally avoids the ambiguity entirely — and immediately makes visible the awkward part of this particular example: 19:30 in Mumbai is a reasonable early evening, but it's worth flagging plainly rather than assuming everyone will separately notice it. If London and New York are both in a summer DST period while Mumbai (which doesn't observe DST) isn't, the gap between the European/US offset and Mumbai's fixed UTC+5:30 shifts by an hour too — another reason to state exact local times for each city explicitly rather than relying on "the usual difference."
A simple habit that prevents most errors
Rather than trying to hold every offset in your head, treat time zone conversion as a lookup, not mental math — check current local times for each participating city at the moment you're scheduling, rather than relying on memory of "the usual" difference, especially near DST transitions or when a half-hour-offset country is involved.
VClock's world clock is built for exactly this kind of quick lookup: pick the cities involved in your call and see their current local time side by side, which makes it easy to spot an awkward hour or a DST-related shift before the invite goes out rather than after someone misses the call.
🌍