UTC Explained: Why Remote Teams Should Think in UTC
If you've spent any time scheduling meetings across multiple time zones, you've probably seen "UTC" come up as a reference point. Aviation, software engineering and financial markets all use it. And for good reason — it's the one time reference that means exactly the same thing everywhere on earth, all year round.
Understanding what UTC actually is, and why it behaves differently from the time zones you deal with day to day, makes global scheduling considerably less confusing.
What UTC actually is
UTC stands for Coordinated Universal Time (the acronym comes from a compromise between the English "CUT" and the French "TUC"). It's the primary time standard by which the world regulates clocks. All other time zones are defined as offsets from UTC: New York is UTC−5 in winter, London is UTC+0 in winter, Singapore is UTC+8, and so on.
UTC is based on atomic clocks — the most accurate timekeeping method available — and is adjusted only by occasional leap seconds to keep it aligned with the Earth's rotation. It has no summer adjustment. It does not spring forward or fall back. Whatever the season, whatever the country, 14:00 UTC is 14:00 UTC.
UTC vs GMT: is there actually a difference?
In everyday scheduling, UTC and GMT (Greenwich Mean Time) are treated as equivalent, and for most practical purposes they are. Both refer to a zero offset — the same point on the clock.
The distinction is technical but worth knowing: GMT is a time zone used by the UK and a handful of other countries during winter. The UK moves from GMT (UTC+0) to BST (British Summer Time, UTC+1) in summer. UTC, by contrast, is a standard, not a time zone. It never changes. A meeting at 14:00 UTC in January and a meeting at 14:00 UTC in July are exactly the same universal moment, even though London's clocks will show different local times for each.
This is why UTC is more useful than GMT as a scheduling anchor. If you say "let's meet at 14:00 GMT," someone might reasonably wonder whether you mean GMT as in UTC+0 or GMT as in British time (which would be BST in summer). "14:00 UTC" is completely unambiguous.
Why UTC never changes
Because UTC is the reference point rather than a local time zone, it has no concept of summer or winter hours. Every local time zone is defined relative to it, and any DST adjustments are expressed as changes in the local offset from UTC — not changes to UTC itself.
When the UK moves to BST in late March, what happens in UTC terms is that London's clocks read one hour ahead of UTC rather than the same as UTC. UTC itself is unmoved. This is why engineers, pilots, air traffic controllers and anyone else who needs unambiguous time references use UTC: local time zones are human constructs layered on top of it, and they change. UTC doesn't.
Common UTC offsets for remote teams
Here are the UTC offsets for major business cities that come up frequently in remote team scheduling:
| City | Standard offset | DST offset | DST period (approx.) |
|---|---|---|---|
| London | UTC+0 (GMT) | UTC+1 (BST) | Late Mar – Late Oct |
| Paris / Berlin / Amsterdam | UTC+1 (CET) | UTC+2 (CEST) | Late Mar – Late Oct |
| New York | UTC−5 (EST) | UTC−4 (EDT) | Mid Mar – Early Nov |
| Chicago | UTC−6 (CST) | UTC−5 (CDT) | Mid Mar – Early Nov |
| Los Angeles | UTC−8 (PST) | UTC−7 (PDT) | Mid Mar – Early Nov |
| Mumbai | UTC+5:30 (IST) | No DST | — |
| Singapore | UTC+8 (SGT) | No DST | — |
| Tokyo | UTC+9 (JST) | No DST | — |
| Sydney | UTC+10 (AEST) | UTC+11 (AEDT) | Oct – Apr (southern hemisphere summer) |
| Auckland | UTC+12 (NZST) | UTC+13 (NZDT) | Oct – Apr (southern hemisphere summer) |
How to use UTC in practice
The most useful habit for distributed teams is to always include the UTC equivalent when communicating a time — especially in text-based channels like Slack, email or project management tools where the reader's calendar app can't automatically adjust.
Instead of writing "let's meet at 3pm London time," write "let's meet at 15:00 UTC (16:00 BST / 11:00 ET / 23:00 SGT)." The UTC anchor lets anyone convert to their local time from a single reference point, without needing to know whether London is currently on GMT or BST.
Some things to keep in mind as you build this habit:
- Use 24-hour format. "2pm UTC" is slightly ambiguous (is that 14:00 or does someone read "2pm" as 2:00 and forget the pm?). "14:00 UTC" is unambiguous.
- State the date too. Because UTC is the same everywhere, a meeting at "23:00 UTC on Thursday" might be Friday morning for people in the Asia-Pacific region. Always clarify the UTC date when times are near midnight.
- Use it in calendar invites. Modern calendar apps (Google Calendar, Outlook, Apple Calendar) all support setting events in a specific IANA time zone. Setting the event in "UTC" or in your local time zone rather than as a raw UTC offset means it will adjust correctly if DST transitions happen between when you booked it and when it occurs.
A quick conversion exercise
To make UTC concrete: say your team has a meeting at 14:00 UTC next Tuesday. Here's what that looks like locally, assuming standard (non-DST) offsets:
- London: 14:00 (same as UTC, London on GMT)
- New York: 09:00 (UTC minus 5)
- Los Angeles: 06:00 (UTC minus 8 — that's early)
- Mumbai: 19:30 (UTC plus 5:30)
- Singapore: 22:00 (UTC plus 8)
- Sydney: 00:00 the following day (UTC plus 10)
That same calculation with a visual tool takes about five seconds. The point of UTC fluency isn't to do the arithmetic in your head — it's to have a stable, unambiguous anchor you can hand to a tool or a colleague, knowing it means exactly the same thing for everyone.
🕐 Convert UTC to local times: Add your team's cities to the MyTimezonePlanner tool and drag the time selector to see the UTC equivalent alongside every city's local time. The generated meeting summary also includes UTC, ready to paste into Slack or an email.
UTC offsets listed in this article reflect standard (non-DST) time. Individual city offsets shift during DST periods. Always verify for specific dates.