Every conversion goes through UTC, and here is why
A local clock reading is a label, not an instant. “14:30” only identifies a moment once you also know the offset from Coordinated Universal Time that was in force at that place on that date. Converting between two zones therefore takes two steps, never one: strip the source offset to recover the UTC instant, then apply the destination offset to relabel it.
Doing it in one step by adding a remembered difference is where mistakes come from. The gap between New York and London is five hours for most of the year, six hours for the two weeks in March when the United States has advanced its clocks and the United Kingdom has not, and four hours for the week in late October when the reverse holds. The difference is a consequence of two independent rules, not a property of the pair of cities, and it changes several times a year.
UTC itself never shifts. It is the international time scale maintained by the Bureau International des Poids et Mesures from a weighted average of atomic clocks, kept within 0.9 seconds of the Earth's rotation angle by the occasional leap second. Every civil time zone is defined as UTC plus a whole number of hours, or in a handful of cases plus a number of half or quarter hours. Routing through UTC means each zone's rule is applied exactly once and in isolation.
Offsets are not evenly spread. They run from UTC−12:00 in the far Pacific to UTC+14:00 in Kiribati, a span of 26 hours, which is why two inhabited places can be on different calendar dates at the same instant. That is the source of the date-rollover figure this calculator reports, and it is the field people most often need and least often check.
The formula, one variable at a time
The source clock reading is converted to a count of seconds: whole days since a fixed epoch, times 86,400, plus 3600h + 60m. Subtracting the effective source offset in seconds gives the UTC instant, and adding the effective target offset gives the destination reading. Because both operations are additions on one number line, the order cannot matter and no ambiguity survives.
The effective offset is the standard offset plus the daylight saving addition: U + D. This calculator asks for the two parts separately and deliberately. Almost every practical error in time zone work is a daylight saving error, and splitting them makes the assumption visible: if you convert to Berlin in July with the DST box unticked, the answer will be an hour early and the reason is on screen rather than hidden in a lookup table.
The daylight saving addition is one hour for every zone that currently observes it, with one live exception — Lord Howe Island in Australia advances by 30 minutes. Historically a few zones used other amounts, including double summer time in wartime Britain. If your case is one of those, enter the total shift in the standard offset field and leave the DST box clear.
Date rollover is what happens when the destination's seconds-past-midnight leave the range 0 to 86,399. Going east across enough zones pushes past midnight and lands you on tomorrow; going west far enough drops back into yesterday. The calculator reports the whole number of days by which the destination's calendar date differs from the source's, so a 23:00 call in New York shows up plainly as a 13:00 call the next day in Tokyo.
Worked example: a 23:00 New York call on 10 January, in Tokyo
You want to place a call at 23:00 on Friday 10 January 2026, New York time, and need the Tokyo date and time. New York's standard offset is UTC−5 and January is outside US daylight saving, so D = 0. Japan has a standard offset of UTC+9 and observes no daylight saving at all, so D = 0 there too.
- Reduce the source reading. 23:00 is 3600 × 23 = 82,800 seconds past midnight on 10 January.
- Effective source offset. −5 + 0 = −5 h = −18,000 s.
- Convert to UTC. 82,800 − (−18,000) = 100,800 s past midnight on 10 January. That exceeds 86,400, so it is 100,800 − 86,400 = 14,400 s on 11 January — 04:00 UTC on Sunday 11 January.
- Effective target offset. 9 + 0 = +9 h = 32,400 s.
- Apply it. 14,400 + 32,400 = 46,800 s on 11 January, which is 46,800 / 3,600 = 13:00 on Sunday 11 January in Tokyo.
- Offset difference. 9 − (−5) = 14 hours, and the date rolled forward by one day.
Sanity-check the rollover independently: 23:00 plus 14 hours is 37:00, and 37 − 24 = 13, one day later. The two routes agree. Note what would have gone wrong with a remembered “Tokyo is 14 hours ahead” rule applied in July instead: New York would be on daylight saving, its effective offset would be −4, and the true difference would be 13 hours, putting the call at noon rather than 13:00.
Standard and summer UTC offsets for widely used zones
| Zone | IANA identifier | Standard | Summer |
|---|---|---|---|
| Hawaii–Aleutian | Pacific/Honolulu | UTC−10:00 | none |
| US Pacific | America/Los_Angeles | UTC−08:00 | UTC−07:00 |
| US Mountain | America/Denver | UTC−07:00 | UTC−06:00 |
| Arizona | America/Phoenix | UTC−07:00 | none |
| US Central | America/Chicago | UTC−06:00 | UTC−05:00 |
| US Eastern | America/New_York | UTC−05:00 | UTC−04:00 |
| Newfoundland | America/St_Johns | UTC−03:30 | UTC−02:30 |
| Brazil (São Paulo) | America/Sao_Paulo | UTC−03:00 | none |
| United Kingdom | Europe/London | UTC+00:00 | UTC+01:00 |
| Central Europe | Europe/Berlin | UTC+01:00 | UTC+02:00 |
| Eastern Europe | Europe/Athens | UTC+02:00 | UTC+03:00 |
| Gulf | Asia/Dubai | UTC+04:00 | none |
| India | Asia/Kolkata | UTC+05:30 | none |
| Nepal | Asia/Kathmandu | UTC+05:45 | none |
| China | Asia/Shanghai | UTC+08:00 | none |
| Japan | Asia/Tokyo | UTC+09:00 | none |
| Australian Eastern | Australia/Sydney | UTC+10:00 | UTC+11:00 |
| Queensland | Australia/Brisbane | UTC+10:00 | none |
| New Zealand | Pacific/Auckland | UTC+12:00 | UTC+13:00 |
| Chatham Islands | Pacific/Chatham | UTC+12:45 | UTC+13:45 |
Offsets and rules change by legislation. Verify against the current IANA time zone database release before relying on a value for a future date.
How to read the result
Check the date-change figure first. A result of +1 means the destination is already on the following calendar date; −1 means it is still on the previous one. Nothing else on the page will alert you if you book a meeting for the right clock time on the wrong day, and that is the single most expensive error this calculation can hide.
The offset difference is signed. A positive value means the destination clock reads later than the source clock at the same instant; a negative value means it reads earlier. It is not a measure of distance and not necessarily what you remember: the difference between two named cities changes several times a year as their daylight saving rules take effect on different dates.
The UTC line is the one to quote when you want a statement that cannot be misread. Logs, incident timelines, flight plans and financial trade records are all kept in UTC precisely because it carries no offset and no seasonal rule. If you are correlating server logs, work in UTC or in epoch seconds throughout and convert only for display — the Unix timestamp converter handles that representation.
Half-hour and quarter-hour zones are not exotic. India, Iran, Newfoundland and parts of Australia use 30-minute offsets, Nepal and the Chatham Islands use 45-minute ones, and this calculator accepts them in 0.25-hour steps. If a converted time lands on a strange-looking quarter hour, it may well be correct.
Mistakes that produce the wrong local time
- Using the current offset for a past or future date. An offset is a function of place and date. Converting a January meeting with July's offset is out by an hour.
- Assuming the gap between two cities is constant. New York to London is five hours for most of the year but four or six for the weeks when only one of them has switched.
- Ticking daylight saving for a zone that does not use it. Japan, China, India, most of Africa, Arizona, Queensland and Hawaii have no summer time at all.
- Reversing the sign of a western offset. New York is UTC−5, so you add five hours to get UTC. Entering +5 puts the answer ten hours out.
- Forgetting the southern hemisphere runs opposite. Sydney is on summer time in January and standard time in July, the reverse of Europe and North America.
- Ignoring the date change. A 23:00 Friday call in New York is a Sunday-morning call in Auckland, not a Saturday one.
- Trusting a three-letter abbreviation. “CST” is US Central, China Standard and Cuba Standard time; the IANA identifier such as
America/Chicagois unambiguous.
The IANA time zone database is the authority
Civil time zones are set by national and regional law, and the definitive machine-readable record of them is the IANA Time Zone Database, maintained collaboratively and shipped inside every operating system, browser and programming language runtime. It records not only current offsets but the full history of rule changes, which is what lets software convert a 1985 timestamp correctly. Releases are named by year and letter, such as 2026a, and are issued whenever a jurisdiction changes its rules — sometimes with only weeks of notice. This calculator asks you for the offsets directly rather than embedding a snapshot of that database, so that it cannot quietly go stale.
Related tools and when to use each
Use this converter when the two readings are in different zones. When they are in the same zone and you want the gap between them, the time duration calculator is the right tool, and it is only valid once both readings share a frame. To combine several durations after conversion, use the add and subtract time calculator.
Around the two annual transition weekends, the daylight saving time change calculator tells you exactly when a jurisdiction switches, which is what you need to decide whether the DST box should be ticked for a given date. For travel, the flight arrival local time calculator combines the offset change with the flight duration in one step, which is the calculation that produces those apparently impossible arrivals before departure.
Astronomical work uses a different convention again: sidereal time and Julian dates are tied to UT rather than to civil zones, and the sidereal time calculator and Julian date calculator handle those. Any observation log should record UTC, because a zone rule change years later can make a locally recorded time impossible to reconstruct.
Key terms
- UTC
- Coordinated Universal Time, the international civil time scale derived from atomic clocks and kept within 0.9 s of the Earth's rotation angle. It has no daylight saving and never changes offset.
- UTC offset
- The signed difference between local civil time and UTC, written as +05:30 or −08:00. Add it to UTC to get local time.
- Daylight saving time
- A seasonal advance of the clock, one hour in almost every jurisdiction that uses it, applied on dates set by law and differing between countries.
- IANA identifier
- The unambiguous name for a zone, in Area/Location form such as America/New_York, as opposed to an abbreviation like EST which several zones share.