Quick answer
Convert both local date-times to UTC using their offsets, subtract there, and present the result with both offsets visible.
Local time is a label
A local date-time is a rendering of an instant, not the instant itself. "9:00 on 16 August" describes different moments in Chicago and in Mumbai, separated by ten and a half hours. Subtracting the two labels as if they were numbers produces a result with no physical meaning.
The reliable procedure has three steps: convert each local time to UTC by subtracting its offset, subtract the UTC values, then present the answer. The intermediate UTC values are worth showing, because they are where a wrong offset becomes visible.
Use this guide with the right tool: Open the Time Zone Date Difference Calculator for the real elapsed interval between two local date-times in different UTC offsets. If the question shifts, compare it with the Date Difference Calculator or the Weekday Calculator.
Offsets are not time zones
An offset is a number of hours from UTC at a particular moment. A time zone is a rule that says which offset applies on which dates. Chicago is UTC−6 in winter and UTC−5 in summer; the zone is constant, the offset is not.
This calculator works with fixed offsets, which is exactly right when you know the offset that applied — for example, when reading it from a timestamp in a log or an email header. It is not right for a future date in a region that observes daylight saving, because the applicable offset may not be the one you expect. For scheduling ahead, work from zone identifiers and a maintained time-zone database rather than from a fixed number.
Half-hour and quarter-hour offsets
Not every offset is a whole number of hours. India is UTC+5:30, Nepal is UTC+5:45, parts of Australia are UTC+9:30, and the Chatham Islands are UTC+12:45. Systems that store offsets as integers silently corrupt these.
If you are entering an offset manually, enter the fractional value — 5.5 rather than 5 — and check the result against a known reference point. A thirty-minute error is small enough to survive review and large enough to move an event across a date boundary.
The date can differ even when the time does not
Because offsets span more than a day in total range, two people can be on different calendar dates at the same instant. A meeting at 22:00 UTC on 16 August is late Sunday evening in London and early Monday morning in Tokyo.
When you communicate a time across zones, give the date in each recipient's local terms, or give the UTC instant and let their calendar render it. Sending only a local time and a zone abbreviation is how people arrive a day late — and abbreviations are ambiguous in their own right, since several are used for more than one zone.
Worked example
Try it with the dates in front of you. Where the answer sits close to a threshold, treat that as a prompt to check the rule rather than to conclude.
Common mistakes to avoid
- Subtracting local times directly. Convert both to UTC first. Direct subtraction of labels is not an interval.
- Storing an offset as a whole number. Several zones use half- and quarter-hour offsets. Use a fractional value.
- Using a fixed offset for a future date. Daylight saving changes the offset. For scheduling ahead, use a zone identifier and a current time-zone database.
Use the right calculator
Three tools cover most of what this guide describes. Each shows its working, so a result can be checked rather than trusted.
Frequently asked questions
Does this handle daylight saving?
No. It applies the offsets you enter. Use it when you know the offsets that applied; use zone-aware software when the offset must be determined for you.
Which offset applies to a past timestamp?
The one in force at that location on that date. Historical time-zone rules change, so a maintained database is the authority.
Why does the tool show UTC values?
Because that is where the arithmetic happens, and seeing them makes an incorrect offset obvious immediately.

