City time zones

Current UTC offset, daylight saving behaviour and business-hub overlap for 29 major cities. 16 of them do not observe daylight saving at all, which is the single most common source of scheduling mistakes on long-running meetings.

Looking for two cities at once? The time difference pages compare working hours hour by hour. To compare more than two, use the interactive grid.

What each page tells you

Every city page carries the same four things: the current UTC offset with the zone's canonical IANA identifier, whether the city observes daylight saving and when it next changes, a table of the local working day mapped against each UTC hour, and an overlap summary against five major business hubs. The figures are recomputed from the timezone database at build time rather than stored, so they survive clock changes rather than going quietly stale.

Why the offset alone is not enough

An offset is a fact about a moment, not about a place. "Berlin is UTC+1" is true in January and false in July. That is why these pages record the IANA zone — Europe/Berlin rather than a fixed number — and derive the offset for the current date. It is also why a team roster listing everyone's offset will be wrong for part of every year, while one listing everyone's city never will be.

The three details that cause the most scheduling errors are all visible on these pages. Half-hour offsets: India, Nepal, Iran, central Australia and Newfoundland are not a whole number of hours from anywhere, so meetings land on the half hour at one end. Zones with no daylight saving: when one city shifts and the other does not, the gap between them changes twice a year even though only one clock moved. Reversed seasons: Australia, New Zealand and Chile enter summer time as the northern hemisphere leaves it, so a north–south gap moves by two hours across the year rather than one.