Time Zone Difference Calculator
Compute the hour gap between two cities using their UTC offsets, with automatic wrap-around across the date line. Useful for scheduling international calls, planning arrivals, and timing jet-lag adjustments.
Last updated: May 2026
Compare with similar
About this calculator
The formula difference = ((destinationTimezone − homeTimezone) mod 24 + 24) mod 24 returns the positive number of hours the destination is ahead of home, in the range 0–23. The double-modulo pattern is what makes the formula safe: a naïve subtraction can return a negative number (e.g., New York −5 vs. Los Angeles −8: −8 − (−5) = −3), which is correct in signed terms but confusing to read. Adding 24 and re-modding folds negatives into the positive 0–23 band. Variables are signed UTC offsets in hours: negative for west of Greenwich (the Americas), positive for east (Europe, Africa, Asia, Oceania). Fractional offsets exist — India is +5.5, Newfoundland is −3.5, Nepal is +5.75 — so allow decimal inputs. Edge cases: a result of 0 means the cities share a time zone; a result of 23 means the destination is effectively 1 hour behind home; a result of 12 means they are exactly opposite. Daylight Saving Time changes offsets seasonally: most US zones shift between standard (e.g., EST UTC−5) and daylight (EDT UTC−4) on different schedules from Europe (which switches a few weeks earlier in spring and earlier in fall). Several countries (Arizona, most of Asia, all of Africa) do not observe DST. Always look up the current offset for your travel dates rather than relying on memory. Half-hour and quarter-hour offsets exist in India (+5:30), Iran (+3:30), parts of Australia (+9:30), and Nepal (+5:45). Crossing the international date line adds or subtracts a calendar day independent of the hour difference.
How to use
Example 1 — east-bound. You live in New York (UTC−5, EST) and travel to Tokyo (UTC+9, no DST). Enter homeTimezone = −5, destinationTimezone = +9. Step 1: raw difference = 9 − (−5) = 14. Step 2: (14 mod 24 + 24) mod 24 = (14 + 24) mod 24 = 38 mod 24 = 14. Tokyo is 14 hours ahead. If you depart New York at 11:00 AM on Monday and the flight is 14 hours, you land at 11:00 AM local Tokyo time on Tuesday (11 + 14 = 25, which is 1:00 AM the next day in New York; add 14 hours to get Tokyo time). Verify: a 10:00 PM video call from your Tokyo hotel = 10 − 14 = −4, wrap to +20 = 8:00 AM the same day in New York. Example 2 — west-bound across the date line. You live in Sydney (UTC+10) and travel to Honolulu (UTC−10). Enter homeTimezone = +10, destinationTimezone = −10. Step 1: raw = −10 − 10 = −20. Step 2: (−20 mod 24 + 24) mod 24 — depending on the language, −20 mod 24 may be −20 or +4; the +24 corrects it: (−20 + 24) mod 24 = 4. Honolulu is 4 hours "ahead" in modular arithmetic, but practically it is 20 hours behind: if it is 6:00 AM Monday in Sydney, it is 10:00 AM Sunday in Honolulu. The calendar day moves backward across the date line even though the clock moves forward by 4. Verify with absolute UTC: 6:00 AM Sydney = 8:00 PM Sunday UTC = 10:00 AM Sunday Honolulu — consistent.
Frequently asked questions
How do I look up the current UTC offset for a city when DST keeps shifting it?
Use a current-data source rather than memory: timeanddate.com, the IANA Time Zone Database (tzdata), or a quick Google search for "current time in [city]" all return the live offset including any DST adjustment. For programmatic work, libraries like Luxon, date-fns-tz, and Python's zoneinfo read the IANA database and handle DST automatically. Be careful with browser-based tools that rely on the user's system clock — if the user has the wrong system time, the displayed offset will be wrong. Several countries have changed DST rules in the last few years (Mexico abolished most DST in 2022, Jordan, Egypt, and Lebanon shifted rules), so older offset tables in apps and articles may be stale. Always check both the home city and destination city for the specific date range of your trip.
Why does the formula use the double-modulo pattern instead of a simple subtraction?
Simple subtraction returns signed values: New York (UTC−5) minus Tokyo (UTC+9) = −14, which is mathematically correct (Tokyo is +14 ahead, so home is −14 behind) but is awkward to display. The first modulo collapses 24-hour rollovers, and adding 24 before the second modulo fixes the fact that the % operator returns negative remainders for negative operands in many languages (JavaScript, C, Java) — for example, (−20) % 24 returns −20, not 4. Adding 24 ensures the value is positive before the final mod, which then guarantees a 0–23 output. Without the +24 step, you would see negative numbers on west-bound results, which most users find confusing. Pythons % operator already wraps to positive, so the second modulo is technically redundant there, but the pattern works correctly in every language.
How can I use the time zone difference to plan international meetings without confusing anyone?
Always quote times in both time zones, marked with the zone abbreviation or UTC offset: "3:00 PM ET / 9:00 PM CET / 20:00 UTC." Tools like worldtimebuddy.com or Google Calendar's time-zone display make this easy. For recurring meetings, beware DST transitions — the US, Europe, and southern hemisphere all switch on different dates, so a meeting that is normally 9:00 AM ET / 3:00 PM CET drifts to 9:00 AM ET / 2:00 PM CET for two to three weeks each spring and fall. Schedulers should pin meetings to UTC if participants span hemispheres. For one-off meetings, send a calendar invite using your home time zone and let the recipient's calendar app convert — most modern clients handle this correctly, but text-only emails saying "3pm Wednesday" are a frequent source of missed calls.
What are common mistakes when computing time zone differences?
The most frequent mistake is using a city's standard offset year-round and forgetting DST — for example, treating New York as UTC−5 all year when it is UTC−4 from mid-March to early November. Another error is mixing standard offsets from one country with daylight offsets from another, which can put a meeting an hour off. People also forget the international date line: a Sydney-to-Los Angeles flight "arrives before it departs" in local-clock terms but actually takes ~13 hours. Half-hour and quarter-hour offsets (India, Iran, Nepal, parts of Australia) get rounded incorrectly to whole hours, putting calls 30–45 minutes off. Finally, some users enter offsets with the wrong sign — UTC−5 is sometimes typed as +5 when reading "5 hours behind UTC," which inverts the entire calculation.
When should I NOT use this calculator?
Skip this tool if you need an exact wall-clock conversion for a specific date, because raw UTC offsets do not capture DST transition dates or historical zone changes. For a single specific moment, use a time-zone-aware library or website that reads the full IANA database — those handle DST, leap seconds, and historical changes properly. Do not use it for flight duration calculations: a flight from New York to London arrives 5 hours later on the clock, but the actual flight time is around 7 hours, not the 5-hour offset. Avoid it for legal or contractual deadlines without secondary verification, since misreading offsets has caused real-world missed deadlines. Finally, for countries currently changing DST rules (e.g., the EU's pending DST abolition or various Middle Eastern shifts), confirm the rule is still in effect for your travel dates before relying on the result.