Timezone Converter

Timezones are the classic example of a problem that looks simple, is not, and punishes approximations. The reliable mental model is that there is only one real time — an instant, measurable as a Unix timestamp — and timezones are ways of displaying it.

Offsets are not timezones

This is the foundational distinction. UTC+1 is an offset: a fixed number of hours to add. Europe/Paris is a timezone: a set of rules describing what the offset is at any moment, including when it changes and by how much.

Paris is UTC+1 in winter and UTC+2 in summer. A meeting stored as "15:00 UTC+1" will be at the wrong local time for half the year. A meeting stored as "15:00 Europe/Paris" is always at 15:00 Paris wall-clock time, whatever the offset happens to be.

The rule: store instants as UTC, store schedules as zone names, and convert at display time.

The IANA database

Every operating system ships a copy. Zones are named Area/Location, where the location is a city whose rules apply to the region:

• Europe/London — not Europe/UK, and not GMT, which is a standard rather than a zone
• America/New_York — covers US Eastern, distinct from America/Chicago
• Asia/Kolkata — UTC+5:30 year round, no DST
• Australia/Sydney — DST in the southern summer, opposite to the northern hemisphere
• Pacific/Auckland — UTC+12, or +13 with DST; one of the first places to see each new day

Aliases exist for backwards compatibility (US/Eastern, GMT, Etc/UTC) but the canonical Area/Location forms are what new code should use.

Why half-hour zones exist

Timezone borders are political. India spans roughly two hours of longitude but adopted a single zone at UTC+5:30 as a national compromise. Nepal sits at +5:45. Afghanistan is +4:30. Myanmar +6:30. Iran was +3:30 until it abolished DST in 2022. Australia has three mainland zones including a +9:30 central zone, and Broken Hill observes a different zone from the rest of New South Wales.

Any code that assumes offsets are whole hours will break on about a third of the world's population.

The two DST edge cases

The gap. When clocks advance, one hour of local time never occurs. 2026-03-29 01:30 does not exist in Europe/London. Scheduling a meeting for that local time is impossible, and libraries handle it by shifting forward — usually to 02:30.

The fold. When clocks retreat, one hour occurs twice. 2026-10-25 01:30 in Europe/London happens first at UTC 00:30 and again at UTC 01:30. An instant stored as UTC is unambiguous; a local time is not, and must be resolved by convention — most systems take the earlier, daylight-saving occurrence.

Both cases matter for cron jobs, billing cycles, medication schedules and anything that runs "at 2am local time".

Finding a meeting time

The overlap problem is not "what is 15:00 Berlin in Tokyo" — it is "which hours are civilised in Berlin, Tokyo and San Francisco simultaneously". The honest answer for that trio is usually a narrow window around 07:00–09:00 Berlin, 14:00–16:00 Tokyo and 22:00–00:00 San Francisco, which means somebody rotates the inconvenience.

Practical heuristics:

• Anchor on the zone with the fewest participants willing to be uncomfortable.
• Check whether either endpoint is in DST while the other is not — the US and Europe are out of step for three weeks in spring and one in autumn, and recurring meetings shift during those windows.
• For truly global teams, record the meeting and publish the UTC time, letting each region convert at the moment they read it rather than the moment you write it.