The world is twenty-six hours wide

Offsets run from UTC−12 to UTC+14, a span of 26 hours. One consequence is that for about two hours of every day, three different calendar dates are in use somewhere on Earth at the same instant — which is why a date on its own is not a time, and why an unqualified deadline of Friday can be a day and a half wide.

Not every offset is a whole hour, either:

Any scheduling logic that assumes offsets are whole hours breaks on roughly a fifth of the world population, most of it in South Asia.

The three weeks a year your recurring meeting moves

Daylight saving changes are not synchronised. The European Union switches on the last Sunday in March and the last Sunday in October. The United States switches on the second Sunday in March and the first Sunday in November. In the gaps:

• Mid-to-late March, about three weeks. New York has moved forward, London has not. The usual five-hour gap is temporarily four.
• Late October to early November, about one week. London has moved back, New York has not. Again four hours instead of five.

A standing call at 14:00 London and 09:00 New York cannot hold both of those times through those weeks. One side moves, and which side moves is whatever the calendar software decided when the invitation was created. This is the single most common cause of somebody joining an hour early, and it is not a bug in anyone tool — it is two governments choosing different Sundays.

Across the equator it is larger. London to Sydney ranges from nine to eleven hours over the year, because the two hemispheres shift in opposite directions and their transition dates do not line up. There is no single correct answer to how far ahead Sydney is.

Within a single country it can vary too. Queensland and Western Australia do not observe daylight saving while New South Wales and Victoria do, so Sydney and Brisbane share a clock for half the year and are an hour apart for the other half. Arizona does not observe it, but the Navajo Nation inside Arizona does, and the Hopi Reservation inside the Navajo Nation does not — so a short drive can cross the same boundary three times.

Working-hour overlap, which is the number you actually need

Knowing the offset is less useful than knowing how much of the day both parties are awake for. Taking a 09:00 to 17:00 day on both sides, from London in summer:

The San Francisco and Sydney rows are the honest answer to a question people keep asking a converter to solve: there is no time that suits both. Something has to give, and the choices are a standing early or late slot, rotating which side absorbs it, or making the work asynchronous. A converter can tell you what 08:00 in one city is in another; it cannot make an overlap exist.

Never write EST when you mean Eastern

Time zone abbreviations are not unique, and several are actively contradictory:

There is a second, quieter error: EST means Eastern Standard Time, which New York is not on in July — it is on EDT. Writing 15:00 EST for a July call names a time that does not currently exist there. Most people read it as Eastern and get it right anyway, but automated parsers do not.

The unambiguous forms are the offset (15:00 UTC+01:00), the full ISO timestamp with offset, or the IANA zone identifier such as Europe/London or America/New_York. Zone identifiers are the right choice because they carry the whole history and future ruleset, not one moment of it.

What a converter genuinely cannot know

The claim that a tool handles all daylight saving rules and always returns the mathematically correct local time deserves qualifying, because it is only true of the past.

Zone rules come from the IANA time zone database, which publishes several revisions a year, and your browser knows only the version bundled with it. Converting a date in the future is therefore a prediction that the current rules will still apply. Governments change them, often with weeks of notice:

• Turkey stopped switching and stayed permanently on UTC+3 in 2016
• Samoa moved across the date line in 2011 and 30 December simply did not happen there
• Mexico ended daylight saving across most of the country in 2022
• Iran abolished its daylight saving in 2022
• Egypt reintroduced daylight saving in 2023 after nearly a decade without it

Two further genuine gaps. On the spring transition an hour of local time does not exist — a 02:30 alarm has no instant to fire at — and on the autumn transition an hour happens twice, so a local timestamp of 01:30 is ambiguous without an offset. Scheduled jobs get skipped or run twice on those two nights every year, and log files from those hours cannot be ordered by their local timestamps alone.

Finally, UTC is not quite the same thing as GMT, and leap seconds have historically been inserted to keep clocks aligned with the rotation of the Earth. The most recent was in 2016, and in 2022 the international body responsible voted to abandon the practice by 2035 — largely because of the trouble a repeated second causes in computing.

Storing times correctly, if you are building something

The rule that saves the most pain: store past events as an absolute instant in UTC; store future appointments as a local time plus a zone identifier.

A meeting set for 09:00 next March in Berlin should stay at 09:00 in Berlin even if Germany changes its rules in the meantime. Store it as an instant and it will silently move to 08:00 or 10:00. A log entry, by contrast, records something that already happened at a fixed instant and belongs in UTC forever. Converting to local time is a display step, done as late as possible.

Questions people actually ask

Why did my recurring call shift by an hour?

Almost certainly a transition gap — the two countries changed their clocks on different Sundays. It corrects itself when the second one switches.

How far ahead is Sydney?

Nine, ten or eleven hours from London depending on the month. Any single figure is wrong for part of the year.

What should I put in a written invitation?

A full date, the time, and either the offset or the city — and for anything crossing more than a few zones, the UTC time alongside it. Abbreviations are the thing to avoid.

Is my location or the times I convert recorded?

No. The conversion uses your device clock and time zone locally in the browser. Nothing is sent to a server, logged or stored.