Time Zone Offset Helper
Converts a date and time between two numeric UTC offsets. It works with offsets rather than named zones deliberately, which makes it exact for the moment you specify and means it will not apply daylight saving rules for you — a distinction worth understanding before relying on the result.
How to use it
- Enter the date and time.
- Enter the UTC offset for each zone in hours, using negatives for west of Greenwich.
- Read the equivalent time in each zone and the offset difference.
An offset is not a time zone
This is the distinction behind most scheduling errors. An offset such as minus five is a fact about one instant. A time zone such as America/New_York is a set of rules that produces the correct offset for any instant, including historical changes and future daylight saving transitions.
New York is UTC−5 in winter and UTC−4 in summer. Storing minus five as a property of a New York meeting is therefore correct for about four months of the year and wrong for the rest. The bug appears at the transition, typically as recurring meetings that shift by an hour for participants in some zones and not others.
Offsets also change by political decision, not only seasonally. Countries have moved zones, abolished daylight saving, and changed transition dates with a few weeks notice. Any future-dated time stored as an offset is a guess about legislation. The correct practice is to store UTC plus a zone identifier for anything that recurs or is scheduled ahead, and to use an offset only for a timestamp that has already happened.
Daylight saving creates two genuinely broken hours
When clocks go forward, a local hour does not exist. In a zone shifting at 2 am, the time 2:30 am never occurs on that date. A validator that accepts it will produce an invalid instant, and a scheduled job set for that time either runs at a different time or does not run at all, depending on the implementation.
When clocks go back, a local hour occurs twice. In a zone shifting at 2 am, 1:30 am happens once before the change and once after, and the two are an hour apart in real time. A local timestamp of 1:30 am on that date is ambiguous and cannot be resolved to an instant without knowing which occurrence is meant.
This produces recurring, predictable failures: duplicate transaction records, jobs that run twice or skip, and shift durations computed an hour out. Southern hemisphere zones transition at the opposite time of year, so a system that handles one hemisphere correctly can fail on the other. The reliable defence is to schedule anything sensitive in UTC and convert for display only.
Not all offsets are whole hours
The assumption that offsets are integers is embedded in a surprising amount of code, and it is wrong.
- India is UTC+5:30, a single zone across the whole country.
- Iran is UTC+3:30, Afghanistan UTC+4:30, and Myanmar UTC+6:30.
- Nepal is UTC+5:45, one of a small number of 45-minute offsets.
- The Chatham Islands are UTC+12:45, becoming UTC+13:45 in daylight saving.
- Parts of Australia use UTC+9:30 and UTC+10:30.
- Offsets range from UTC−12 to UTC+14, a span of 26 hours, which means three calendar dates can be in progress simultaneously.
Scheduling across zones
A few habits remove most of the practical difficulty.
State the zone explicitly and unambiguously. Abbreviations are not reliable: CST means both North American Central Standard Time and China Standard Time, IST means Indian, Irish, and Israeli Standard Time, and several others collide. A city name or an IANA identifier is unambiguous where an abbreviation is not.
Prefer 24-hour notation in cross-border communication, since am and pm are read inconsistently and 12 am is genuinely ambiguous to many readers. And include the UTC time alongside the local one for anything important, since UTC is the one figure every participant can convert from without knowing your daylight saving state.
Finally, note that the transition dates themselves differ. The United States and Europe change on different weekends, so the offset between New York and London is five hours for most of the year and four for a couple of weeks in spring and autumn. Recurring meetings across the Atlantic shift twice a year for exactly this reason.
At a glance
| Input | Numeric UTC offsets in hours, negative for west |
|---|---|
| Daylight saving | Not applied, offsets are taken as given |
| Offset range | UTC−12 to UTC+14 in practice |
| Transmitted | Nothing |
Frequently asked questions
Why use offsets instead of named zones?
Offsets are exact for the instant you specify. Named zones need the full rule database, including future daylight saving changes that are subject to legislation.
What happens during a daylight saving change?
One local hour ceases to exist and another occurs twice. Times in those hours are invalid or ambiguous, which is why sensitive scheduling should be done in UTC.
Are all offsets whole hours?
No. India is UTC+5:30, Nepal UTC+5:45, and the Chatham Islands UTC+12:45. Code that assumes integer offsets is wrong.
Why is the London to New York gap not always five hours?
Because the two regions change clocks on different weekends. For a couple of weeks in spring and autumn the difference is four hours.
Read more
Working with dates and time — Days are exact, months are a convention, and two hours a year do not exist or happen twice.