Time zones look like simple arithmetic and are not. The offsets are not all whole hours, they change twice a year on dates that differ by country, some places ignore the changes entirely, and the abbreviations everyone uses are ambiguous. Almost every scheduling mistake traces back to one of a small number of misconceptions, and this guide covers them.

UTC is the reference, and it never changes

UTC — Coordinated Universal Time — is the standard every other zone is defined against. Critically, UTC does not observe daylight saving. It is the same all year, which is exactly why it is the only sane thing to anchor to.

GMT is often used interchangeably, and for everyday purposes the difference is irrelevant. Technically GMT is a time zone (the one the UK uses in winter) while UTC is a time standard. The confusing consequence: London is not always GMT. From late March to late October it is on British Summer Time, UTC+1.

Offsets are not all whole hours

A surprising number of places sit on a half or quarter hour:

  • UTC+5:30 — India, Sri Lanka
  • UTC+5:45 — Nepal
  • UTC+9:30 — parts of Australia (Adelaide, Darwin)
  • UTC+12:45 — Chatham Islands, New Zealand
  • UTC−3:30 — Newfoundland, Canada
  • UTC+3:30 — Iran

Any code or mental model that assumes whole-hour offsets will produce wrong answers for hundreds of millions of people.

Daylight saving is where scheduling actually breaks

The trap is not that clocks change. It is that different countries change on different dates, so the gap between two cities is not constant.

  • United States: second Sunday in March to first Sunday in November
  • European Union & UK: last Sunday in March to last Sunday in October
  • Australia: October to April — the opposite half of the year, being southern hemisphere

New York and London are normally five hours apart. But for the roughly three weeks between the US spring change and the EU one, they are four hours apart. The same thing happens for a week in autumn. A recurring meeting set as “2pm New York, 7pm London” silently becomes wrong twice a year.

Plenty of places skip DST entirely: most of Arizona, all of Hawaii, most of Asia and Africa, and all of India and China. China is a single time zone across a landmass that geographically spans five.

Never store an abbreviation or a raw offset

This is the most consequential rule for anyone building software, and it explains a whole class of bugs.

“EST” is not New York.EST is Eastern Standard Time, UTC−5, which New York uses only in winter. In summer New York is on EDT, UTC−4. Storing “EST” for a New York user means every summer date is an hour off.

Abbreviations are also ambiguous across regions. CST can mean US Central Standard Time (UTC−6), China Standard Time (UTC+8), or Cuba Standard Time. IST can mean India, Ireland or Israel.

Store the IANA time zone identifier instead — America/New_York, Europe/London, Asia/Kolkata. These name a place, and the tz database maps that place to the correct offset for any given date, including all historical rule changes. The time zone converter works from IANA identifiers for this reason.

The rule for storing timestamps

Store in UTC. Convert to local time only at the moment of display.

One important exception: for future events tied to a wall clock — a 9am recurring standup, a calendar appointment a year out — store the local time andthe IANA zone, not a UTC instant. Governments change DST rules with little notice, and if that happens your stored UTC instant will resolve to the wrong local time. Storing “9am in Europe/Berlin” stays correct through a rule change; storing “08:00 UTC” does not.

Unix timestamps

A Unix timestamp is the number of seconds since 1 January 1970 UTC. It has no time zone — it is a single instant, identical everywhere on Earth. That property makes it excellent for storage, logging and comparing events, and useless for displaying to a human without converting first.

Two practical notes. JavaScript's Date.now() returns milliseconds, not seconds, which is a very common off-by-1000 bug when interoperating with systems that use seconds. And 32-bit signed timestamps overflow on 19 January 2038 — the Year 2038 problem — which is why 64-bit storage is now standard. The Unix timestamp converter translates in both directions.

Write dates unambiguously

03/04/2026 is 3 April to most of the world and 4 March in the United States. There is no way to tell from the string which is meant.

Use ISO 8601 for anything written down or exchanged between systems: 2026-04-03, or with a time, 2026-04-03T14:30:00Zwhere the trailing Z means UTC. It sorts correctly as plain text, it is unambiguous, and it is an international standard. For anything a person reads, spelling the month out — “3 April 2026” — removes all doubt.

Scheduling across zones in practice

A few habits eliminate most missed meetings:

  • Always state the zone.“3pm” is not a time. “3pm UTC” or “3pm Europe/Berlin” is.
  • Name a city, not an abbreviation.“9am New York time” is unambiguous in a way that “9am EST” is not.
  • Send calendar invitations rather than times in prose. Calendar software handles the conversion and the DST edge cases for everyone automatically.
  • Double-check meetings near a DST boundary — the weeks around mid-March, late March, late October and early November.
  • Watch the date, not just the hour. A 4pm Friday call in Los Angeles is 9am Saturday in Sydney. Cross-Pacific scheduling crosses the date line as well as the clock.

For finding an overlap across several places at once, the world clock shows current local time in major cities side by side, and the time difference calculator gives the gap between two specific clock times.

The short version

  • UTC is the anchor and never shifts.
  • Offsets are not always whole hours.
  • DST dates differ by country, so the gap between two cities changes.
  • Store IANA zone names, never abbreviations or raw offsets.
  • Store instants in UTC; store future wall-clock events as local time plus zone.
  • Write dates as ISO 8601.
  • Always say which zone you mean.