Timezone Offset Calculator
Convert a time from one timezone to another given the UTC offsets of both. The simplest case of timezone arithmetic — useful for cross-time-zone meetings, travel planning, and reading wall-clock times across regions.
Last updated: May 2026
Compare with similar
About this calculator
A timezone is defined by its offset from Coordinated Universal Time (UTC) — for example, US Eastern Standard Time is UTC−5, China Standard Time is UTC+8, India Standard Time is UTC+5:30. To convert a wall-clock time from timezone A (offset off_A) to timezone B (offset off_B), the formula is: time_B = time_A + (off_B − off_A), with modular arithmetic to wrap around the 24-hour clock. This calculator computes: result_hour = (timeHour + (timezone2 − timezone1)) modulo 24. Variables: timezone1 is the origin timezone's UTC offset in hours (e.g., −5 for US Eastern Standard); timezone2 is the destination timezone's offset (e.g., +8 for China Standard); timeHour is the wall-clock hour at the origin (0–23). The result is a wall-clock hour in 24-hour format at the destination. Edge cases: the modular arithmetic correctly handles day-rollover for very negative or very positive offset differences (e.g., 22:00 in Los Angeles UTC−8 → +14 hours to UTC+6 New Delhi → 22 + 14 = 36 → 36 mod 24 = 12:00, with date advanced by 1 day). The calculator doesn't track the date change, only the hour-of-day. Half-hour offsets (India +5:30, Newfoundland −3:30, Nepal +5:45) require fractional inputs, which work but produce non-integer outputs. Daylight Saving Time (DST) makes things worse: during DST, US Eastern shifts from UTC−5 to UTC−4, so a "fixed" offset isn't actually fixed across the year. Real timezone conversion in production software uses tz database (IANA) which tracks historical DST changes per region; this calculator handles only the simple fixed-offset arithmetic. Edge cases worth noting: some places near the International Date Line have offsets like +12, +13, +14 (Samoa, Kiribati), and on the other side −11, −12; converting across the IDL can flip the date by 24 hours.
How to use
Example 1 — Trans-Pacific meeting. You're in New York (UTC−5) and want to schedule a meeting with someone in Beijing (UTC+8). What's 14:00 New York time in Beijing? Enter Origin Timezone Offset = −5, Destination Timezone Offset = 8, Time = 14. Result = ((14 + (8 − (−5))) + 24) mod 24 = (14 + 13 + 24) mod 24 = 51 mod 24 = 3. ✓ 14:00 NYC = 03:00 Beijing the next day. Confirming: 14:00 EST = 19:00 UTC = 03:00 CST + 24 hours, so it's 03:00 the following day. The calculator returns the hour but not the date change. Example 2 — Europe to Australia. London (UTC+0 in winter) at 09:00 to Sydney (UTC+10 in their winter, +11 in summer). Use +10 for now. Enter 0, 10, 9. Result = ((9 + 10) + 24) mod 24 = 19. ✓ 09:00 London = 19:00 Sydney — late dinner time, manageable for international calls. In southern hemisphere summer (Sydney AEDT +11), 09:00 London = 20:00 Sydney. The hour difference can flip during the transition periods around DST changes (UK changes early March/late October, Sydney changes early October/early April — the windows when the offset gap is briefly 9 or 10 hours instead of the usual).
Frequently asked questions
How does daylight saving time complicate timezone conversion?
DST means a region's UTC offset isn't fixed — it shifts an hour twice a year. US Eastern Time alternates between UTC−5 (EST, winter) and UTC−4 (EDT, summer). UK shifts between UTC+0 (GMT, winter) and UTC+1 (BST, summer). When you convert between two regions that have DST, the offset gap changes seasonally — most of the year it's the "standard" gap, but during DST transitions and when one region has DST while the other doesn't, the gap shifts. Different countries change DST on different dates: US Federal switch on 2nd Sunday in March / 1st Sunday in November; EU on last Sundays of March / October. Some countries don't observe DST at all (India, China, Japan, most equatorial countries). For accurate timezone conversion, use a library that consults the IANA tz database (Python's pytz, JavaScript's Intl.DateTimeFormat, etc.) rather than fixed offsets; this calculator assumes static offsets and will be off by an hour during partial DST periods.
What's the difference between UTC and GMT?
In practice they're used interchangeably to mean "the same time as London in winter, before DST." Technically: UTC (Coordinated Universal Time) is the modern atomic-clock-based time standard, defined to within microseconds; GMT (Greenwich Mean Time) is the historical solar-time standard based on the Sun's position at the Royal Observatory in Greenwich, London. UTC includes leap seconds (added irregularly to keep it within 0.9 s of solar time), while GMT historically was solar; the two have diverged by tens of seconds since 1972 but for ordinary use the difference is invisible. Both are at UTC offset 0. The UK calls its winter time "GMT" and its summer (DST) time "BST" (British Summer Time, UTC+1). For international computer systems, always use UTC; for human-readable wall clocks in the UK, GMT/BST are the conventional terms.
Why do some places have half-hour or quarter-hour offsets?
Historical decisions and political/economic factors. Most countries chose offsets in whole hours from UTC for simplicity, but a few opted for half-hour shifts to better match local solar time given the country's longitude. India uses UTC+5:30 (mid-country longitude is around 82°E, which would naturally suggest +5:30); Nepal uses UTC+5:45 (the only quarter-hour offset, established to be different from India); Iran uses UTC+3:30; Afghanistan UTC+4:30; Newfoundland (Canada) UTC−3:30; central Australia UTC+9:30 (and +10:30 in DST). The proliferation of non-whole-hour offsets is largely historical accident; some have proposed simplifying global timezones to whole-hour offsets, but inertia and existing legal/contractual references make change unlikely. Software handling timezones must support these fractional offsets — and yes, computer bugs from assuming integer offsets are a real source of date/time errors.
What are the most common mistakes with timezone conversion?
The first is using a fixed offset for a region that observes DST — half the year you're off by one hour. Always use the region's name (e.g., "America/New_York") with an IANA-aware library, not a numeric offset. The second is forgetting to track the date change for large conversions; converting 22:00 LA to Tokyo (offset gap 17 hours) crosses a day boundary and is "15:00 next day", which a single hour-of-day result obscures. The third is confusing "destination offset" with "source offset"; getting them backwards reverses the conversion. The fourth is assuming all places in a country are the same timezone — US, Russia, Canada, Australia, Brazil, and others span multiple timezones. The fifth is ignoring historical changes: a meeting "at 9 AM in Moscow on 2010-10-30" was during a different offset than the same wall-clock time today, because Russia changed its DST policy in 2011. For historical or future date conversion, use a tz database; static-offset calculators get historical dates wrong by an hour.
When should I not use this calculator?
Skip it for dates near DST transitions, when the offset is changing — the static-offset arithmetic gives a wrong answer at the discontinuity. Don't use it without checking whether both source and destination observe DST; if one does and the other doesn't, the offset gap changes seasonally. It's the wrong tool for converting historical dates (anything more than a few years ago); time zone definitions and DST policies have changed in many countries, and historical conversion needs the IANA tz database. Avoid it for places near the International Date Line (UTC+12 to UTC−12); apparent "small offset differences" can hide a 24-hour date change. For production software (calendar apps, distributed systems, financial systems), never use a hand-coded offset calculator — always use a properly-maintained tz library that gets updated whenever any country changes its DST rules (which happens every few years somewhere in the world).