Understanding time zones
Same instant, different clocks.
A time zone is not a place. It's a rule for naming a moment.
UTC, the anchor.
Every time zone is described as an offset from Coordinated Universal Time — UTC. London in winter is UTC+0, Tokyo is UTC+9, Los Angeles is UTC−8. Multiply that offset by 3,600 seconds, add it to a Unix timestamp, and you have the wall-clock time in that zone. Subtract to go the other way. UTC itself is the same number everywhere on earth — the rendering is what differs.
local = UTC + offset
Zones aren't fixed offsets.
A common trap is treating "EST" or "GMT" as a constant. New York is UTC−5 in winter and UTC−4 in summer; the same zone, two offsets. The IANA database, which every modern operating system ships, captures this with names like America/New_York — a recipe for which offset applies on which historical date, including future DST transitions, leap seconds, and one-off political decisions.
Daylight saving — the half-yearly catch.
Most temperate countries shift their clocks forward in spring and back in autumn — but not on the same date, not by the same amount, and increasingly not at all. The European Union is phasing it out; Russia abolished it in 2011 and reinstated it in part in 2014; Mexico ended most observance in 2022. When you schedule a meeting "every Tuesday at 09:00 New York time," the UTC instant of that meeting moves twice a year. The IANA zone is the only thing safe to record.
Half-hour and quarter-hour offsets exist.
About a billion people live in zones that are not on a whole hour boundary. India runs at UTC+5:30, Iran at UTC+3:30, Newfoundland at UTC−3:30. Nepal sits on UTC+5:45 — a quarter past the hour. Code that assumes integer hours of offset will produce subtly wrong wall-clock times for these places.
The two date trick.
For any single instant, the world holds two calendar dates at once. While London reads Friday morning, Sydney reads Friday afternoon and Honolulu still reads Thursday evening. The world clock on this page splits its rows into those date-buckets so you can see, at a glance, where the calendar boundary is — a common thing to misread when scheduling across many regions.
What to store, what to display.
The pragmatic rule: store moments as UTC (or as a Unix timestamp, which is the same idea), and store the zone as an IANA name — never a fixed offset and never a "EST"-style abbreviation. At display time, use the user's zone to render. Following this rule means your data survives DST changes, political redraws, and the user moving across an ocean.
What this tool can and can't do.
The converter above uses your browser's IANA database — the same one your laptop checks when daylight saving flips. It handles every zone, half-hour offsets included, with transitions for the next several years. It can't predict zones that haven't been published yet (a country deciding to abandon DST in 2027 only shows up after the database is updated), and it doesn't know your meeting calendar — so when DST shifts mid- schedule, you'll need to revisit any time you committed to in terms of an offset rather than a zone.