How to Schedule Meetings Across Time Zones

Why time zone mistakes keep happening

Almost everyone who schedules meetings internationally has a story: the call that started at 3 a.m. for one person, the customer who waited in an empty room an hour early, the webinar announced for a time that does not exist.

These mistakes are rarely about carelessness. They happen because humans do time zone arithmetic in their heads using assumptions that are true most of the time — "London is five hours ahead of New York" — and the exceptions are exactly where the errors live.

The fix is not to be more careful. It is to stop doing the arithmetic by hand, and to know which situations are dangerous enough to double-check. A wrong time zone is also one of the simplest causes of a no-show to remove.

The daylight saving trap

The single most common source of cross-border scheduling errors is that countries do not change their clocks on the same day.

The United States moves to daylight saving time on the second Sunday in March and back on the first Sunday in November. The European Union and the United Kingdom change on the last Sunday in March and the last Sunday in October. For a few weeks each spring and autumn, the gap between New York and London is four hours instead of the usual five.

A recurring meeting set up in February at "2 p.m. London, 9 a.m. New York" will drift for those weeks unless the calendar system anchors it to a specific time zone. Someone turns up an hour early or an hour late, usually without realising why.

It gets more interesting further afield:

• The southern hemisphere changes in the opposite direction. Parts of Australia move their clocks forward in early October, as Europe and North America are preparing to move theirs back. The gap between Sydney and London can shift by two hours across a few weeks.
• Many places do not observe daylight saving at all, including India, China, Japan, and most of Africa, and within Australia, Queensland does not while New South Wales does. The offset to these places changes when your clocks change, not theirs.
• Rules change. Countries adjust or abolish daylight saving with relatively little notice. Anything that hard-codes offsets will eventually be wrong.

Practical consequence: in March, April, October, and November, treat every cross-border meeting as worth a second look.

Offsets that are not whole hours

Most people assume time zones differ by whole hours. Several large ones do not.

India is UTC+5:30. Nepal is UTC+5:45. Parts of Australia use half-hour offsets, and Newfoundland in Canada sits at a half-hour offset as well. When a scheduling tool or a person rounds these to the nearest hour, meetings land thirty or forty-five minutes off — close enough to seem like lateness rather than a system error, which makes the cause hard to spot.

If your team or customers include any of these regions, test your scheduling setup against them specifically.

Abbreviations are ambiguous

"The call is at 10 a.m. EST."

That sentence is wrong for most of the year. EST is Eastern Standard Time, which applies only in winter; in summer the eastern United States is on EDT. Most people mean "Eastern time, whatever it currently is", and most people reading it will interpret it that way — but not all of them, and not all software.

Other abbreviations are worse. IST can mean India Standard Time, Irish Standard Time, or Israel Standard Time. CST can mean US Central Standard Time or China Standard Time, which are thirteen or fourteen hours apart.

Safer alternatives:

• Name a city: "10:00 New York time". Everyone knows what that means, and it stays correct through daylight saving.
• Give the UTC offset when precision matters: "10:00 UTC−4".
• Let the calendar invitation carry the time zone and let each recipient's calendar display it in their local time. Put the human-readable version in the body as a courtesy, not as the source of truth.

Store one time, display many

If you build or configure scheduling systems, the underlying rule is simple: store every meeting as a single instant in time, attached to a named time zone, and convert only for display.

That means:

• A meeting is stored as, for example, "14:00 in Europe/London on a specific date", or as a UTC timestamp — never as "2 p.m." with the zone implied.
• Recurring meetings are anchored to the organiser's named zone, so they follow that zone's daylight saving rules deliberately rather than by accident.
• Every person sees the time converted to their own zone, and every message that states a time also states which zone it is in.

Systems that store local times without a zone, or that store fixed offsets like "UTC−5" instead of named zones like "America/New_York", are the ones that break twice a year.

Finding a fair time for everyone

Some combinations of locations have no good meeting time. San Francisco, London, and Singapore span most of the clock; someone will be on early or late.

A few approaches keep this sustainable:

• Rotate the inconvenience. If a recurring meeting is always at 7 a.m. for the same person, that person pays the whole cost. Alternating between two times spreads it.
• Protect the edges. Agree hard limits — for example, nothing before 7 a.m. or after 8 p.m. local time — and let the scheduling system enforce them as rules rather than relying on people to object.
• Question whether it needs to be live. A written update with a shorter live discussion for the people who can attend often works better than a meeting nobody is fully awake for.

To see where everyone's working hours overlap on a specific date, our free meeting time zone converter shows each attendee's local time and lists the hours that fall inside working time for all of them.

For events, time zones cut the other way: everyone is in the same place, but the pre-event scheduling happens across many zones. Confirmations sent weeks before a conference should always state the meeting time in the venue's local time, clearly labelled, because that is the time that will matter on the day. Getting it wrong is one of the avoidable causes of no-shows at event meetings.

Rules worth adopting

• Never use time zone abbreviations on their own; name a city or give an offset.
• Store meetings with named time zones, never bare local times or fixed offsets.
• Anchor recurring meetings to one named zone, deliberately.
• Double-check cross-border meetings in March, April, October, and November.
• Test your setup against half-hour offsets if you work with those regions.
• Put limits on acceptable local hours and enforce them as scheduling rules.
• For events, state times in the venue's time zone.

CallShark is being built to store every booking against a named time zone and show each participant their own local time. The product is temporarily down.