Working across time zones

Everyone who works across time zones eventually joins a call an hour early, or an hour late, or discovers that a standing meeting has quietly moved for half the team. The causes are always the same handful of things, and none of them are your arithmetic.

Time zones are not fixed offsets

The first mistake is treating a time zone as a number. "New York is UTC−5" is true for about four months of the year. For the other eight it is UTC−4.

A time zone is not an offset — it is a set of rules about which offset applies on which dates, and those rules are set by governments and change with little notice. The tz database that every operating system relies on is updated several times a year because some country somewhere has changed its mind.

This is why you should always name a zone rather than an offset. "3pm Europe/London" is unambiguous forever; "3pm GMT+1" is only correct until the clocks change. The time zone converter works from real zone names for this reason, and hovering across the grid shows every zone at once so you can see the offsets that actually apply on the date you care about.

Some offsets are not even whole hours. India is UTC+5:30, Nepal UTC+5:45, parts of Australia UTC+9:30, and the Chatham Islands UTC+12:45. Software that assumes whole hours breaks in these places, and so do people doing mental arithmetic.

Daylight saving is the real villain

Almost every recurring-meeting disaster traces back to daylight saving, for one reason: countries do not change their clocks on the same day.

The EU and UK move on the last Sunday in March and October. The US moves on the second Sunday in March and the first Sunday in November. That leaves roughly three weeks in spring and one in autumn when the usual gap between London and New York is four hours instead of five.

The southern hemisphere is inverted — Australia and New Zealand enter daylight saving as Europe leaves it — so the gap between London and Sydney swings between 8, 9, 10 and 11 hours across the year. And plenty of places never change at all: most of Asia, Africa and South America, all of Japan, China, India and Russia, and within the US both Arizona and Hawaii.

If you have a weekly call between a country that observes daylight saving and one that does not, that call moves for one of you twice a year, guaranteed. This is not a bug in your calendar; it is the world being inconsistent.

UTC, GMT and why they are not the same

They point at the same clock face but they are different things.

GMT is a time zone — the one the UK uses in winter. In summer the UK is on BST, one hour ahead. So a British colleague saying "GMT" in July is very probably an hour out, and "9am GMT" in June is genuinely ambiguous.

UTC is a time standard, not a zone. Nobody's civil time is permanently UTC. It never observes daylight saving, which is exactly what makes it useful: it is the fixed reference every other zone is defined against.

For anything written down — a deadline, a launch time, a log entry, an API contract — use UTC and say so. For anything a human reads, use their local time and name the zone. The Unix timestamp converter is handy here, since Unix time is seconds since 1970 in UTC and has no time-zone problem at all.

Finding the overlap

The practical question is rarely "what time is it there" and almost always "when are we both awake".

A useful frame: assume a working window of roughly 09:00 to 17:00 local. Two zones four hours apart share about four hours. Eight hours apart share almost nothing — London and Los Angeles overlap from about 17:00 to 18:00 London time, which is 09:00 to 10:00 in California.

Once you pass about nine hours of separation there is no civilised overlap at all, and someone is dialling in outside their working day. Rotate who that is. A standing 07:00 call that always falls on the same team breeds quiet resentment.

The time zone converter shows a full day as a grid across every zone you add, so the overlap is visible rather than calculated. The world clock is better for an at-a-glance check of what time it is right now in the places you care about.

Rules that stop meetings drifting

• Anchor recurring meetings to one city, and say which. "Weekly sync, 10:00 America/New_York" means the meeting follows New York's clock changes. Everyone else adjusts. Without an anchor, every calendar makes its own guess.
• Send calendar invitations, never times in prose. An invitation carries the zone rules; a message saying "Thursday at 3" carries nothing. This single habit prevents most errors.
• Put the zone in the meeting title. It survives being forwarded, screenshotted and pasted into a chat.
• Re-check every recurring meeting in March, April, October and November. Those are the four windows when offsets shift.
• Use 24-hour time in writing. "7:00" is ambiguous to half the world; "19:00" is not.
• Never say "my time". The reader does not know your time and may not know where you are.

For a deadline that is genuinely fixed, a countdown timer sidesteps the question completely — everyone sees the same remaining duration regardless of where they are.

When to stop scheduling altogether

Past a certain spread, synchronous work stops being worth its cost. If your team spans more than about eight hours, the honest answer is usually to move most communication to writing.

Write decisions down rather than making them in a call the other half of the team could not attend. Record the meetings that must happen and post the recording. Keep the synchronous time for the things that genuinely need it — disagreements, ambiguity, anything with feelings attached — and let everything else be read at a sensible hour.

The teams that handle time zones well are not the ones with the best converters. They are the ones that need fewer meetings.

Pikkit has the clocks, timers and converters, and Calculators & Time collects the time tools in one place.