Time Zone Converter — Convert Time Between Cities & Time Zones

The IANA Time Zone Database (also called "tz database", "Olson database" after Arthur David Olson who founded it in 1986, or "zoneinfo") is the canonical source of historical UTC offsets and DST rules for every region — currently ~600 zone definitions covering every UTC offset change, DST transition, and political timezone decision since 1970. Current release: 2026a (March 2026), maintained by Paul Eggert (UCLA) with multiple updates per year as governments change rules. Why use canonical zone IDs (Europe/Madrid, America/New_York, Asia/Tokyo) instead of timezone abbreviations: abbreviations are ambiguous (CET can mean Central European Time UTC+1 or, in some legacy code, Central Equatorial Time UTC+0; CST means US Central, China Standard, or Cuba Standard depending on context). The zone ID encodes the full history (Madrid was UTC+0 until 1942, briefly UTC+2 during WW2, UTC+1 since then with DST since 1974) — a single ID resolves any historical or future date correctly.

EU: per Directive 2000/84/EC of 19 January 2001, spring-forward last Sunday of March at 01:00 UTC (= 02:00 → 03:00 CET); fall-back last Sunday of October at 01:00 UTC (= 03:00 → 02:00 CET). EU Parliament voted to abolish DST in March 2019 but final Council decision still pending; Member States would individually choose permanent winter (UTC+1) vs summer (UTC+2) time. United States: per Energy Policy Act 2005 (extended starting 2007), spring-forward second Sunday of March at 02:00 local; fall-back first Sunday of November at 02:00 local. Arizona (except Navajo Nation), Hawaii, Puerto Rico, Guam, US Virgin Islands, American Samoa, Northern Mariana Islands do not observe DST. Australia: state-by-state — NSW, Victoria, SA, Tasmania, ACT observe DST (October-April, opposite hemisphere); Queensland, NT, WA do not. Brazil: permanently abolished DST in 2019 (Decree 9.772 of 25 April 2019, Bolsonaro administration). Russia: abolished DST 2011, reintroduced different rules 2014. Türkiye: permanent UTC+3 since 7 September 2016 (Resmi Gazete decree). Morocco: permanent WET+1 (= UTC+1) since 26 October 2018 (Decree 2-18-855). Japan, China, India: no DST.

When DST spring-forward fires, clocks jump from 02:00 directly to 03:00 — the 02:00:00 to 02:59:59 window does NOT exist in local time on that date. Conversely, fall-back makes 02:00-02:59 occur twice (once before clocks go back, once after). Programming gotchas: a recurring meeting scheduled at 02:30 local in EU on spring-forward Sunday has no valid local time — different libraries handle this differently (Python `pytz` raises NonExistentTimeError, JavaScript silently shifts forward, Java ZonedDateTime offers strategies). For fall-back, a timestamp logged as "02:30 local" is ambiguous about which of the two occurrences it means. RFC 3339 with explicit offset (`02:30-04:00` vs `02:30-05:00` for atraso del reloj US Eastern) disambiguates; storing in UTC eliminates the problem entirely. Tools handling user-facing recurring events should explicitly skip non-existent times or pick a documented strategy.

ISO 8601-1:2019 timezone offset notation: `Z` = UTC (zero offset, often used in logs and APIs); `±HH:MM` = explicit offset from UTC. Worked examples: `+00:00` = UTC (same as Z); `+01:00` = Madrid winter, Berlin winter, Casablanca year-round; `+02:00` = Madrid summer, Berlin summer, Athens winter, Istanbul (post-2016 permanent); `+03:00` = Moscow, Riyadh, Istanbul (permanent); `+05:30` = India Standard Time + Sri Lanka; `+03:30` = Iran (DST +04:30 abolished September 2022); `+06:30` = Myanmar + Cocos Islands; `+09:30` = Adelaide standard; `-03:30` = Newfoundland; `-09:30` = Marquesas Islands (further half-hour offsets); `+05:45` = Nepal; `+12:45/+13:45` = Chatham Islands NZ (only two 45-minute offsets in current use); `+09:00` = Tokyo, Seoul; `-05:00` = US Eastern winter; `-08:00` = US Pacific winter. RFC 3339 requires an explicit offset (no naive datetime). UTC offsets change historically — Russia moved Moscow from UTC+3 to UTC+4 in 2011, back to UTC+3 in 2014.

Choose a reference timezone (often UTC or one participant's home) and explicitly state both the local time and offset. Example: "9:00 EST (UTC-5) Tuesday" = 14:00 UTC = 15:00 CET (winter) / 16:00 CEST (summer) = 19:30 IST (UTC+5:30) = 23:00 JST (UTC+9). Common gotchas: DST changes shift the offset for half the year (US Eastern is UTC-5 winter / UTC-4 summer); Madrid is UTC+1 winter / UTC+2 summer; Sydney is opposite-hemisphere so UTC+10 winter / UTC+11 summer (their winter = our summer). The IANA tz database resolves these correctly when given a zone ID (America/New_York, Europe/Madrid, Australia/Sydney) — the tz database holds the political and DST rules so the same zone ID produces different offsets for different dates. For calendar invitations, prefer storing UTC + offset (RFC 3339) and converting per-recipient; ICS calendar files include the zone ID via the VTIMEZONE component referencing IANA names.