Converting between time zones looks trivial and is one of the most error-prone things in everyday computing. The arithmetic is easy; the traps are all in the details — a single country with two time zones, a DST rule that changes on different dates in different places, and a date line that adds or removes a whole day.
Everything goes through UTC
A UTC offset is how many hours a local time is ahead of or behind Coordinated Universal Time. Tokyo is +9, London is +0 in winter and +1 in summer, New York is −5 in winter and −4 in summer. The conversion is then two steps, always through UTC:
UTC = local time − offset, then target local = UTC + target offset
Worked example. A call at 09:00 in New York (offset −5, so winter) is 09:00 + 5 = 14:00 UTC. In London (offset 0) that is 14:00. In Tokyo (+9) it is 14:00 + 9 = 23:00 the same day.
The step people skip is that the offsets must come from the date in question, not from a table they remember. This is not a detail — it is the whole difficulty.
The daylight saving trap
Most of the world shifts its clocks by one hour twice a year, but the rules are not coordinated:
- The US changes on the second Sunday in March and the first Sunday in November.
- The EU changes on the last Sunday of March and October — so for three weeks each year the US and Europe disagree about the offset.
- China and India do not observe DST at all, so their offsets are fixed year-round.
- Most of Australia observes it in the opposite half of the year to the northern hemisphere, because the seasons are reversed.
So a meeting agreed "at 9am UK time" in the last week of October may be an hour off for a US participant. The safe rule is simple: store the offset, not the local time, and re-verify offsets when a recurring meeting crosses a DST boundary.
Two days in one year when the clock is wrong
At the spring transition the local clock jumps from 01:59:59 to 03:00:00, so the times 01:30 and 02:15 do not exist on that day. A reminder set for 02:00 will either never fire or fire an hour later, depending on the system. In autumn the hour repeats, so 01:30 happens twice — and "the daily standup at 01:30" is genuinely ambiguous on that one day.
Neither is a bug in your software; it is a consequence of the civil convention. Schedules that must not drift should be specified in UTC and displayed in the user's local zone.
The offset is not always a whole number of hours
India is UTC+5:30, Nepal +5:45, parts of Australia +9:30, and some historical zones were offset by odd amounts like +8:45. Code that assumes integer hours will be wrong for a large part of the world, and quietly wrong: a 30-minute error rarely looks like a bug.
There is a second reason offsets used to be odd. Before standard time was adopted, each city kept its own local mean time — the noon when the sun was highest. That differs by a few minutes per degree of longitude, so adjacent cities ended up with slightly different clocks. Standard time collapsed those into zones, but the fractional parts were already there.
The International Date Line
Crossing east to west, you subtract a day and gain time; crossing west to east, you add a day. This is where the 24-hour mistake usually happens: a flight from Tokyo to Los Angeles departs one calendar day and arrives on the same named day, because it crossed the line and gained a day back. A Tokyo 09:00 departure arriving in LA the same calendar day is 09:00 + 17 hours = 02:00 the next day in UTC terms, then −8 hours = 18:00 the previous day local. Always work out the day name as well as the clock time.
A practical checklist
For anything that has to be right rather than approximately right:
- Convert to UTC first, using the offset for the specific date, then convert to the target zone.
- Store UTC (or a UTC timestamp) and format at display time. Never store a local time string.
- Label the zone explicitly — "09:00 UTC" is unambiguous; "09:00" is not.
- Check both dates for DST when the conversion spans a boundary, and re-check recurring meetings twice a year.
- Do not assume integer offsets if the other party might be in India, Nepal or Australia.
None of this is difficult once it is explicit. The failures happen when the offset is carried in someone's head rather than in the code.
Three ways the conversion goes wrong
The arithmetic is one line; almost every failure is one of three specific mistakes.
1. Using yesterday's offset. Offsets are functions of a date, so a meeting recurring weekly crosses a DST boundary twice a year and is silently wrong from one Sunday to the next. A calendar application that stores the offset rather than the zone name will not update it. Store the IANA zone (Europe/London, not GMT+1) and let the library recompute.
2. Forgetting the date rolls over. Going east can push you into tomorrow, going west into yesterday, and the error is a whole day rather than an hour. The mental shortcut of "add nine hours" silently loses this because it only tracks the clock face, not the calendar.
3. Assuming the offset is symmetric. The distance from London to Tokyo is 9 hours in winter but 8 in summer, because only one of the two observes DST. There is no fixed number for any pair of zones that involves at least one DST country, which is most of them.
What UTC does and does not solve
UTC removes the ambiguity of which time is authoritative, and it is what systems should store. It does not remove the need to think about the user's experience: nobody schedules a meeting in UTC, they schedule it in their own zone and expect it to display correctly for everyone else.
The clean pattern is a three-layer design:
- Store an instant in UTC — a Unix timestamp or an ISO 8601 string with a
Zor explicit offset. - Compute using the target zone and the instant's date, so DST is applied correctly.
- Display in the viewer's zone, with the zone label visible so nobody has to guess.
Storing a naive local string like "2026-10-04 09:00" is the failure mode to avoid: it has no offset attached, so it is meaningless once it leaves the building, and it becomes wrong twice a year even if it does not move.
Two more offsets that surprise people
leap seconds. UTC occasionally adds a second so that it does not drift against the Earth's rotation. There have been 27 since 1972, and they are almost always announced six months ahead. A leap second makes a day 86401 seconds long, which breaks the assumption in any code that computes "days between two timestamps" by dividing by 86400. On platforms that do not handle it, the count is simply one second out — harmless for calendar arithmetic, relevant for precise measurement.
Time zones are not geography. Russia has 11 time zones across one country; the United States has more than the report's own content would suggest; China uses a single zone (UTC+8) across a country spanning 73° of longitude, which means the sun can be almost five hours off schedule at its western edge. The reason is historical: time zones were adopted to serve rail networks and telegraph operators, and political boundaries won.
None of this is exotic. It is the ordinary state of timekeeping, and a system that assumes otherwise will be wrong for a meaningful fraction of users at some point in the year.
Frequently asked questions
How do I convert between time zones?
Work in UTC: take the source local time, subtract its UTC offset to get UTC, then add the target's offset. The offset is not fixed — it depends on whether daylight saving is in effect on the specific date, which is why you must look up two dates rather than one.
What is UTC and why is it useful?
UTC is the reference time zone, kept at exactly zero offset by agreement. Because it never shifts, converting through it removes the ambiguity of working directly between two local times, and it is what every computer and protocol stores internally.
Why do time zones have half-hour and 45-minute offsets?
They are historical accidents of political decisions. India's +5:30 reflects a 1930s decision to be 5.5 hours ahead of Greenwich; Nepal's +5:45 exists for similar reasons. Offsets need not be whole hours, which is a common source of conversion bugs.
What actually happens at daylight saving transitions?
In spring most of the world jumps forward an hour, so the local time 01:30–02:59 does not exist on the transition day. In autumn the hour repeats, so 01:30–02:59 happens twice. Anything scheduled inside those windows needs explicit disambiguation.