Time Zone Converter

Background.

This time zone converter takes a clock time and a source UTC offset, routes it through Coordinated Universal Time, and returns the matching wall-clock time at any destination UTC offset on the planet — with full support for the fractional offsets civil time really uses, a day-shift counter that tracks when conversion crosses midnight, and a UTC pass-through that exposes the canonical timestamp the world's scientific, aviation, and financial systems agree on. Civil time is built on a deceptively simple idea: every location on Earth has an integer or fractional hour offset from a single global reference, UTC, and converting between two cities is just (source time) minus (source offset) plus (destination offset), wrapped into the 0–1439 minute range with a day-shift bookkeeping bit.

In practice the simplicity is undermined by three things human beings consistently get wrong. First, daylight saving time. Saying 'New York is UTC-5' is true in January and false in July — the actual offset on the ground swings between -5 (Eastern Standard) and -4 (Eastern Daylight) on the second Sunday of March and the first Sunday of November each year, and the dates differ between the United States, the European Union, the United Kingdom, Australia, and the dozens of countries that have changed or abolished DST in the last decade. The bullet-proof move for any cross-border meeting is to look up the current offset on the day of the meeting and feed that integer or fraction into a converter that takes offsets rather than zone names. This tool deliberately accepts offsets, not zone names, so the answer never silently drifts because a DST rule changed in Cairo, Santiago, or Lord Howe Island.

Second, fractional offsets. Most people assume time zones are full-hour ticks, but a non-trivial slice of the world's population lives on half-hour or quarter-hour offsets: India and Sri Lanka are UTC+5:30, Nepal is UTC+5:45, Iran is UTC+3:30, Newfoundland is UTC-3:30, the Marquesas Islands sit on UTC-9:30, and the Chatham Islands of New Zealand keep UTC+12:45 (UTC+13:45 in their summer). A converter that only accepts integer offsets quietly mis-schedules every Indian, Nepalese, Iranian, Newfoundlander, and Chatham Islander meeting it touches. This calculator's offset input accepts any quarter-hour value from -12 to +14, which covers every offset the IANA Time Zone Database currently lists.

Third, the international date line. Conversion that crosses 180° longitude — say, Samoa (UTC+13) calling American Samoa (UTC-11) — produces a same-clock-time answer one calendar day apart, and the day-shift output is the only safe way to keep the date straight.

Below the widget you will find a tour of UTC itself (it is not the same as GMT for high-precision work — UTC includes leap seconds, GMT historically did not), a breakdown of ISO 8601 versus RFC 3339 timestamp formats, the canonical source of all real-world zone data (the IANA tz database maintained at iana.org/time-zones, descended from Arthur David Olson's 1986 release and adopted by every Unix-based system on Earth), and worked examples for business-hour overlap windows, transpacific call planning, and the peculiar geometry of the Chatham Islands' 45-minute offset. Whether you are scheduling a Zoom call with a team in Bangalore, planning a layover in Auckland, or just trying to remember whether London is five or four hours ahead of New York this week, the converter folds the arithmetic into one HH:MM answer and one day-shift bit.

What is time zone converter?

A time zone converter is a function that maps (clock-time, source-offset) to (clock-time, destination-offset) by routing through Coordinated Universal Time. Civil time on Earth is defined as UTC plus a location-specific offset — an integer or quarter-hour fraction in the closed interval [-12, +14] — and converting between two locations is purely arithmetic: subtract the source offset to get UTC, then add the destination offset to get local time at the destination, then normalise the result into the [0, 1440) minute-of-day window while tracking whether the answer fell on the previous, same, or next calendar day. UTC itself is the international civil time standard maintained jointly by the International Bureau of Weights and Measures (BIPM) and the International Earth Rotation and Reference Systems Service (IERS); it ticks at the rate of atomic time (TAI) but is adjusted by occasional leap seconds to stay within 0.9 seconds of solar time (UT1). The set of (zone-name, offset, DST-rule) triples used in actual civil schedules is the IANA Time Zone Database (the 'tz database' or 'zoneinfo'), originally compiled by Arthur David Olson in 1986 and now maintained by Paul Eggert and a public technical committee — it ships inside every Linux distribution, macOS, iOS, Android, Java runtime, Python, and PostgreSQL install in the world. This calculator deliberately operates on raw UTC offsets, not zone names, because zone-name resolution silently changes whenever a country amends its DST rule (Mexico abolished most of its DST in 2022; Brazil abolished its in 2019; Egypt reinstated DST in 2023), and a tool that hard-codes those rules will eventually mis-schedule a meeting. Pick the offset that is actually in effect at the source and destination on the meeting date — the tool will do the arithmetic exactly.

How to use this calculator.

1. 01Enter the source clock time in 24-hour format: hour 0–23, minute 0–59. 1pm in the source city is 13; 11:30pm is 23 hours, 30 minutes. The calculator does not accept AM/PM.
2. 02Enter the source location's current UTC offset in hours. New York in winter is -5; in summer (EDT) it is -4. London in winter is 0; in summer (BST) it is +1. India is +5.5 year-round (no DST).
3. 03Enter the destination location's current UTC offset, again as it stands on the day of the meeting. Tokyo +9, Sydney +10 (or +11 in their summer), Los Angeles -8 (or -7 PDT).
4. 04Read the primary output, destination hour, alongside the destination minute — together they form the wall-clock time someone in the destination zone reads off their watch.
5. 05Check the day-shift output. 0 means same calendar date as the source. +1 means the call lands on the next day at the destination (common for evening-Pacific to morning-Asia calls). -1 means the call lands on the previous day at the destination (common for morning-Asia to late-night-Americas calls).
6. 06Use the UTC hour and UTC minute outputs as a sanity check or to log the meeting in canonical UTC — the format aviation, financial trading systems, and scientific telemetry all use as the universal reference.

The formula.

The calculator does all its work in minutes-of-day arithmetic, then re-splits the answer into hours and minutes at the end. Step 1: source_total_minutes = source_hour × 60 + source_minute. This collapses the 24-hour clock into a single integer in [0, 1439]. Step 2: utc_total_minutes = source_total_minutes − fromOffsetHours × 60. Subtracting the source offset removes the local-zone adjustment and gives the canonical UTC clock time, which is the only common ground all zones share. Note that utc_total_minutes can be negative (if the source is east of UTC and the source clock is early enough) or greater than 1440 (if the source is west of UTC and the source clock is late enough). That is fine — we will normalise later. Step 3: dst_total_minutes = utc_total_minutes + toOffsetHours × 60. Adding the destination offset shifts UTC into the destination's local clock. Again the intermediate value may be negative or above 1440. Step 4: dayShift = floor(dst_total_minutes ÷ 1440). This integer counts how many whole calendar days the destination time is offset from the source date. A value of −1 means the destination is the previous day, 0 means the same day, +1 means the next day. Step 5: normalised = ((dst_total_minutes mod 1440) + 1440) mod 1440. The double-modulo is the standard JavaScript idiom for non-negative remainder — vanilla x % 1440 returns negative values for negative x. The result is a clean integer in [0, 1440). Step 6: convertedHour = floor(normalised ÷ 60); convertedMinute = normalised mod 60. The UTC outputs are derived the same way from utc_total_minutes. The whole pipeline is closed-form integer arithmetic — no calendar libraries, no Date object pitfalls, no DST guesswork — which is why it stays correct for any offset the IANA database ever defines.

A worked example.

Frequently asked questions.

References& sources.

1. [1]IANA Time Zone Database (tz database / zoneinfo). Maintained by Paul Eggert and the IANA tz coordination team. The canonical source of UTC offsets and DST rules for every civil zone on Earth.
2. [2]BIPM, Coordinated Universal Time (UTC). Bureau International des Poids et Mesures, the international authority that, jointly with the IERS, defines and disseminates UTC.
3. [3]NIST, Time and Frequency Division — UTC reference and frequently asked questions. The U.S. National Institute of Standards and Technology's primary public reference on UTC, leap seconds, and the relationship between UTC, GMT, and TAI.
4. [4]ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules. International Organization for Standardization. The current edition of the international standard for date-time encoding, including UTC offset notation.
5. [5]Mills, D. L., Martin, J., Burbank, J., Kasch, W., RFC 5905: Network Time Protocol Version 4 — Protocol and Algorithms Specification, IETF, June 2010. The protocol that disseminates UTC across the Internet to billions of devices, descended from David Mills' original NTP work at the University of Delaware.
6. [6]Klyne, G., Newman, C., RFC 3339: Date and Time on the Internet — Timestamps, IETF, July 2002. The IETF profile of ISO 8601 used by virtually every modern Internet protocol.