Time zones and UTC: why “meet at 9” breaks, and the fix

“Let’s meet at 9” is a perfectly good sentence when everyone is in the same building. It stops being one the moment the group spans two countries — because the instant you meant by “9” is a different time of day for everyone else, and the relationship between your clocks changes twice a year without anyone deciding it should. This is the problem UTC exists to solve, and it is the one habit that makes distributed scheduling reliable: name the instant, not the wall time.

What UTC is

Coordinated Universal Time is the fixed clock every other clock is measured against. Every time zone on Earth is defined as an offset from it — Warsaw is UTC+1, New York UTC−5 — and when a zone observes daylight saving, it is the offset that changes, not UTC. This is the whole point: UTC does not move, so a time written as 12:00 UTC means the same instant in Warsaw, New York, and Tokyo, whether it is January or July.

The practical rule for scheduling follows directly: agree on the UTC instant, then let each location convert it to local wall time. The meeting is one instant; the 9:00 is the local face of it, and each zone gets its own face.

How offset math works

The conversion is subtraction and addition:

target time = source wall time − source offset + target offset

Both offsets are read at the instant being converted — never a fixed “summer” or “winter” value, because the offset on a January date differs from the offset on a July date for the same zone. Worked example: 14:00 in Warsaw during summer (UTC+2):

• 14:00 − 2h = 12:00 UTC
• 12:00 − (−4h) = 08:00 in New York (UTC−4 in summer)

The same instant, three clocks. The table shows a full spread:

UTC instant	Warsaw (UTC+2, summer)	New York (UTC−4, summer)	Tokyo (UTC+9)
08:00	10:00	04:00	17:00
12:00	14:00	08:00	21:00
15:00	17:00	11:00	00:00 (next day)
22:00	00:00 (next day)	18:00	07:00

Note what the table exposes: a meeting at a “reasonable” time in one city is midnight in another, and the UTC column is the only one that reads the same for everyone. That is exactly why the UTC column is the one to book from.

Why “meet at 9” breaks — the DST asymmetry

Most people know offsets change twice a year. What surprises them is that they do not all change on the same day. Europe moves to summer time on the last Sunday of March and back on the last Sunday of October; the United States moves on the second Sunday of March and the first Sunday of November. The calendars disagree — so for about three weeks each spring and one week each autumn, Warsaw and New York sit at 5 hours apart instead of their usual 6, with nobody’s clock having “changed” recently from their own point of view.

Concretely: in late October, New York is still on daylight time (UTC−4) while Warsaw has already fallen back (UTC+1). A 9:00 meeting in New York that was 15:00 in Warsaw the previous week is suddenly 14:00 in Warsaw. The weekly slot shifted by an hour without any calendar invite updating — the class of failure that fixed-offset planning cannot see, because every zone looks consistent when viewed from inside.

There is also the stranger edge: a local time that does not exist. On a spring-forward day, 02:30 is skipped entirely in zones that advance at 02:00 — the correct handling is the standard convention of shifting forward, and the honest converter flags it rather than pretending the time exists. On a fall-back day the same local time exists twice, and the earlier offset is the convention. Both cases are why the time-zone converter computes the offset at the exact instant you convert, never from a fixed table.

The awkward offsets

Rounding is a luxury the world does not share. India runs UTC+5:30, Nepal UTC+5:45, the Chatham Islands UTC+12:45 — and a few zones observe daylight saving in half-hour or 45-minute steps. Any tool that snaps to whole hours is silently wrong for about a fifth of the world’s population, which is precisely why zone names are the right input: identifiers like Europe/Warsaw or America/New_York name one zone unambiguously, while abbreviations like “CST” mean Central, China, and Cuba Standard Time simultaneously. The offset is a property of a zone at an instant, not a label that travels.

Let the calculator do it

The time zone converter takes a source zone, a date and time, and a target zone, and returns the target time, the UTC instant, and both offsets at that exact moment — with spring-forward and fall-back times resolved by the standard conventions and flagged on the page. The meeting overlap planner goes one step further: add each team’s zone and local work window, pick a date, and it computes the overlap windows in UTC with local start and end times for every zone — evaluating every minute of the day in local wall time, so a zone that changes offset mid-day cannot shift the result. When no window exists it says so plainly rather than proposing an impossible time, which is the honest answer a distributed team actually needs. For the recurring case, the business days calculator handles the calendar side, and the rule of thumb remains: re-check any fixed weekly slot around the transition dates.

The one rule

Quote the UTC instant and let each location convert it — “meet at 9” becomes “meet at 14:00 UTC”, which is 15:00 in Warsaw, 09:00 in New York, and 23:00 in Tokyo, and means the same instant for all of them. The moment someone offers you a time without a zone and a date, the sentence is incomplete; the conversion tools exist because that incompleteness is where meetings go wrong.