How to use
Add cities to the list (Seoul, Tokyo, New York, London, San Francisco — wherever your colleagues sit). The current time in each city shows live and the time-slider at the top lets you scrub through the day to find a slot that fits everyone. Each row also shows the UTC offset, whether the city is currently in daylight saving time, and the date relative to your local zone (so a 9 AM Seoul slot on March 5 might show as "March 4, 7 PM" for San Francisco — the same instant, a different calendar day).
Reach for this when scheduling a cross-timezone meeting, debugging a server log that emits UTC timestamps you need to reason about in local terms, or planning travel where flight times bridge multiple zones. DST transitions are handled by the browser through the IANA tz database — pick `America/Los_Angeles` and the converter switches between `PST` and `PDT` automatically. Everything runs locally; no city list is uploaded, no clock is fetched from a server.
Examples
9 AM Seoul → other zones
Input
cities: Seoul, Tokyo, San Francisco, New York, London
slider: Seoul 09:00 (March 5)
Output
Seoul 09:00 Wed Mar 5
Tokyo 09:00 Wed Mar 5
San Francisco 17:00 Tue Mar 4 (PST)
New York 20:00 Tue Mar 4 (EST)
London 01:00 Wed Mar 5 (UTC)
Note the date shift: 9 AM Wednesday in Seoul is still Tuesday evening in San Francisco and 1 AM Wednesday in London. For a global meeting, the "tolerable for everyone" sweet spot is often Seoul afternoon (your evening for US-east, US-west afternoon) — slide the time slider to test.
DST transition example
Input
cities: Tokyo, New York
slider: New York 02:30 (March 8)
Output
Tokyo 16:30 Sun Mar 8
New York invalid (DST spring-forward 02:00 → 03:00)
On the second Sunday of March, US eastern time skips from 02:00 directly to 03:00 — 02:30 simply does not exist that day. The converter detects this and shows "invalid" rather than silently picking 02:30 EST or 02:30 EDT. The reverse happens on the first Sunday of November, where 01:30 happens *twice* in one day (once EDT, once EST); some tools flag this as ambiguous, others pick the first occurrence.
Same offset, different rules
Input
cities: London (Europe/London), Lisbon (Europe/Lisbon)
date: November 2
Output
London UTC+00:00 (GMT, just exited BST)
Lisbon UTC+00:00 (WET, just exited WEST)
Two cities can share the same offset *today* but differ at other times of year because their DST rules diverge. London moves from BST (UTC+1) to GMT (UTC+0) on the last Sunday of October. Lisbon moves on the same day but uses different names (WEST → WET). On November 2 both are UTC+0, but in summer London is +1 and so is Lisbon — same shift, different labels. Always identify by IANA name (`Europe/London`, `Europe/Lisbon`), not by abbreviation.
FAQ
Why use IANA names like `Asia/Seoul` instead of just `KST`?
IANA names identify a *zone with rules*, abbreviations only identify a *current offset*. `KST` is unambiguous (Korea has no DST since 1988) but `CST` could mean China (UTC+8, no DST), US Central (UTC−6 / −5 with DST), or Cuba (UTC−5 / −4 with DST). `BST` is British Summer Time in Europe but Bangladesh Standard Time in Asia. IANA names like `America/New_York` carry the full DST schedule and historical changes, so the same string works correctly today, in 1980, and after any future DST policy change. Always store and pass zones as IANA names; render to abbreviations only at display time.
When does DST actually happen?
It varies by country and changes occasionally. **USA / Canada**: second Sunday of March (spring forward) and first Sunday of November (fall back); the change is at local 02:00. **EU / UK**: last Sunday of March and last Sunday of October; the change is at 01:00 UTC for all member states. **Australia**: first Sunday of October and first Sunday of April (only southern states observe). **Most of Asia, Africa, and South America**: no DST. Korea dropped DST in 1988; Japan in 1952; China centralizes everything on UTC+8. The IANA tz database tracks every rule change going back to ~1970, plus historical estimates for earlier dates.
Is "midnight" 00:00 or 24:00?
Both — they refer to the same instant but on different calendar days. `00:00 March 5` and `24:00 March 4` are the same moment in time. ISO 8601 prefers `00:00` for human display but allows `24:00` for the end-of-day boundary in contracts ("this offer expires at 24:00 on March 4" makes the cutoff clear without ambiguity about whether midnight starts March 5). Avoid `12:00 AM` / `12:00 PM` notation when precision matters — many people misread the AM / PM assignment for midnight and noon. Use 24-hour or "00:00" / "noon" / "midnight" explicitly.
How accurate is the browser's timezone database?
Modern browsers (Chrome / Edge / Safari 2023+) ship the latest IANA tz database baked in, updated roughly every browser release (~6 weeks). DST rule changes announced more than a release-cycle in advance work correctly; emergency changes (Egypt cancelled DST a few times with weeks notice) may lag for 1–2 release cycles. For server-side code where rule changes need to land faster, use a runtime tz library that pulls updates from npm or pip (`tzdata` packages publish updates within days of IANA releases).
How do I store a "future meeting at 9 AM Seoul" in a database?
Store as a pair: the local wall time (`2026-06-15 09:00`) plus the IANA zone (`Asia/Seoul`). Do *not* convert to UTC at write time, because if Korea ever changes its DST rules (it has not since 1988 but governments revisit this) the stored UTC value becomes wrong. Convert local + zone to UTC only at render time, against the *current* tz database. PostgreSQL has `timestamp` + a separate `text` column for the zone; some apps use a single `timestamptz` plus a zone column. The same advice applies to recurring events: store `RRULE:FREQ=WEEKLY;BYHOUR=9` in the meeting's home zone, not in UTC.
Why is the offset half an hour or 45 minutes in some places?
A handful of countries use half-hour or quarter-hour offsets, historical artifacts of pre-1972 standardization. **India** is UTC+05:30 (one zone for the whole country, splits the longitude difference between east and west). **Iran** is UTC+03:30. **Afghanistan** is UTC+04:30. **Nepal** is UTC+05:45 (the only quarter-hour zone in regular use, set to 0:15 offset from India). **Chatham Islands**, NZ is UTC+12:45 / 13:45. The IANA tz database handles all of these correctly; just identify them by IANA name (`Asia/Kolkata`, `Asia/Tehran`, `Asia/Kathmandu`, `Pacific/Chatham`).
Related concepts
A time zone is a region that agrees on a wall-clock offset from UTC plus a set of rules for when (if ever) to shift by an hour for daylight saving. The **IANA tz database** (also called the Olson database, named after Arthur David Olson who started it in 1986) is the authoritative source for these rules. Every modern operating system and runtime ships some form of it — Linux `/usr/share/zoneinfo`, macOS `/var/db/timezone`, Windows ICU bundles, Node.js `Intl.DateTimeFormat`. The database identifies zones by `Continent/City` (e.g., `Asia/Seoul`, `America/New_York`, `Europe/Berlin`) rather than by political boundary, because rules sometimes diverge within a country.
The **separation of instant from local time** is the core abstraction. A Unix timestamp like `1741132800` is an absolute instant — the same moment everywhere on Earth. The rendering of that instant as a wall-clock time depends on which zone you ask: `2025-03-05 09:00 KST` and `2025-03-04 16:00 PST` are the same instant. Mixing these up is the source of most calendar bugs. The rule is: store instants in UTC for past events; store `(local_time, zone)` for future events because the zone's rules may change before the event happens.
Three adjacent ideas matter. **UTC** (Coordinated Universal Time) is the global reference; offsets are expressed relative to it. **Leap seconds** are occasional 1-second adjustments to UTC, last applied in December 2016; Unix time intentionally ignores them, but TAI and GPS time count them, so the offsets diverge by 37 seconds as of 2026. The international meeting to abolish leap seconds (after 2035) is in progress. **DST policy** is genuinely chaotic — Russia abandoned it in 2011, the EU has been "about to" abandon it since 2019, Brazil dropped it in 2019, many US states have legislation pending. Treat any future-DST assumption as fragile; lean on the tz database as the single source of truth and update it regularly.
