How to Schedule Across Time Zones Without Getting It Wrong

Everyone who works across time zones eventually joins a call an hour early, or misses one entirely. It’s rarely carelessness. It’s usually one of three specific traps, all of which are avoidable once you know what they are.

Trap one: the offset you memorised is seasonal

London to New York is five hours. Except when it isn’t.

The US moves to daylight saving on the second Sunday in March. The UK and EU move on the last Sunday in March. For roughly three weeks in between, New York has sprung forward and London hasn’t — so the gap is four hours, not five.

The same thing happens in reverse in autumn. The EU falls back on the last Sunday in October; the US waits until the first Sunday in November. Another week of four-hour difference.

That’s about a month a year when the offset every regular caller has internalised is simply wrong. Predictably, that’s when meetings get missed.

Southern hemisphere countries shift in the opposite direction, which means the gap between London and Sydney varies across the year by a full two hours.

The fix: always convert for the specific date, never apply a remembered offset. If you’re scheduling something six weeks out, check it for that date.

Trap two: ambiguous abbreviations

Three-letter time zone abbreviations are not unique, and some of the collisions are spectacular.

Abbreviation	Could mean	Offset
CST	US Central Standard	UTC−6
CST	China Standard	UTC+8
CST	Cuba Standard	UTC−5
IST	India Standard	UTC+5:30
IST	Irish Standard	UTC+1
IST	Israel Standard	UTC+2
BST	British Summer	UTC+1
BST	Bangladesh Standard	UTC+6
AMT	Amazon	UTC−4
AMT	Armenia	UTC+4

CST spans fourteen hours depending on which one you meant. “Let’s meet at 9am CST” between a team in Chicago and one in Shanghai is not a scheduling instruction; it’s a coin flip.

The fix: write the UTC offset. “09:00 UTC−6” is unambiguous in a way that “9am CST” never is.

Trap three: forgetting it’s a different day

Sydney is 9 to 11 hours ahead of London depending on the season. When it’s 4pm Monday in London, it’s already 2am Tuesday in Sydney.

“Let’s do 9am Tuesday” from a London sender means Tuesday in London, which for the Sydney recipient is Tuesday evening — or possibly Wednesday morning, depending on the hour. Neither party thinks they’ve been ambiguous.

The fix: always include the date alongside the time, and quote both local times explicitly.

The half-hour and quarter-hour zones

Not every offset is a whole number of hours, which breaks a lot of mental arithmetic:

• UTC+5:30 — India, Sri Lanka
• UTC+5:45 — Nepal
• UTC+9:30 — parts of Australia
• UTC+3:30 — Iran
• UTC−3:30 — Newfoundland
• UTC+8:45 — a small part of Western Australia
• UTC+12:45 — Chatham Islands

India being at UTC+5:30 catches people out constantly. If it’s 09:00 in London (UTC+1 in summer), it’s 13:30 in Mumbai, not 13:00 or 14:00.

Who doesn’t change their clocks

Most of the world, in fact. Daylight saving is largely a European, North American and Australasian practice.

No daylight saving: India, China, Japan, most of Africa, most of South America, Russia, most of the Middle East, and every country near the equator, where day length barely varies.

Recently abolished it: Turkey, Russia, Mexico (2022), and several others. Rules change more often than you’d expect, which is a good argument for letting software handle it rather than a spreadsheet of offsets you maintain by hand.

Finding a slot that actually works

With participants spread across enough longitude, a mutually reasonable hour may not exist. Practical guidance:

Europe and Asia — European morning, Asian afternoon. London 09:00 is Singapore 16:00, Mumbai 13:30, Tokyo 17:00. Comfortable for everyone.

Europe and the Americas — European afternoon, American morning. London 15:00 is New York 10:00, San Francisco 07:00. The classic transatlantic slot.

Americas and Asia — genuinely hard, with no good answer. US evening against Asian morning is the least bad: San Francisco 17:00 is Tokyo 09:00 the next day, Singapore 08:00.

All three at once — accept that someone is getting an unsociable hour, and rotate who it is. Always defaulting to the convenience of head office is a real and quietly corrosive cost for everyone else.

And consider whether the meeting needs to happen at all. For a fifteen-person global sync, a written update that everyone reads in their own working hours often serves better than forcing a third of the participants awake at 05:00.

Writing a time nobody can misread

Send a calendar invitation. This is the actual answer. Every calendar client converts to the recipient’s local time automatically, and the whole class of problem disappears. Everything below is for when you can’t.

Use the 24-hour clock. “19:00” cannot be misread; “7:00” plus a missing “pm” can.

Include the date and the day. “Tuesday 14 April” is harder to get wrong than “Tuesday”.

Anchor on UTC, then translate. A good format:

Tuesday 14 April, 15:00 UTC (16:00 London · 11:00 New York · 20:30 Mumbai · 23:00 Singapore)

Spell out the zone if you must abbreviate. “US Central” rather than “CST”.

Don’t write “GMT” when you mean “UK time”. The UK is on GMT in winter and BST in summer. UTC never changes, which is exactly what makes it useful as an anchor.

For recurring meetings

A weekly call fixed at “15:00 London” drifts relative to New York twice a year, and relative to Sydney twice more. Everyone gets a calendar entry that quietly becomes an hour wrong.

Two options. Either fix it to one city’s local time and accept that other participants see it shift — but say so explicitly, so nobody assumes an error. Or fix it to UTC and accept that everyone’s local time shifts. The first is usually kinder if one location holds most participants.

Whichever you choose, state it in the invitation. “This meeting follows London time and will move by an hour for other regions in late March and late October” takes one line and prevents a year of confusion.