How we calculate these figures
Every offset, transition date and overlap window on this site is computed rather than typed in by hand. This page explains where the data comes from, how the calculations work, and — just as importantly — what they do not account for.
Where the timezone data comes from
All timezone information originates from the IANA Time Zone Database, the reference dataset that records every civil timezone rule and historical change worldwide. It is the same dataset used by Linux, macOS, Android, iOS and every major programming language.
We do not ship our own copy of it, and we do not query a timezone API. Instead the calculations run through the browser's built-in Intl.DateTimeFormat, which exposes the IANA data already present in the operating system or browser:
new Intl.DateTimeFormat('en-US', {
timeZone: 'America/New_York',
hour12: false,
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit', second: '2-digit'
}).formatToParts(date)Comparing that local wall-clock reading against the same instant in UTC gives the offset in minutes. This approach has one significant consequence worth stating plainly: the timezone rules are as current as your browser. When a country changes its clock rules, the fix arrives through a browser or OS update rather than through us, which is usually faster than a site maintaining its own table.
Why not a timezone API? An API introduces a network dependency, a rate limit, and a second source of truth that can disagree with the device the reader is actually using. Reading the platform's own database means the tool shows you the same time your calendar will.
Cities and their zones
The built-in list covers 126 cities, each mapped to its canonical IANA zone identifier — Europe/London, Asia/Kolkata, America/Sao_Paulo and so on. We store the zone identifier rather than a fixed offset, because an offset is a fact about a moment while a zone is a fact about a place. A city stored as "UTC+1" would be wrong for half the year; a city stored as Europe/London is never wrong.
If you search for a city outside that list, the tool falls back to OpenStreetMap's Nominatim geocoder to resolve the name to coordinates, then maps those coordinates to an IANA zone using the tz-lookup library. That path is less precise near zone boundaries than the curated list, so the built-in cities are preferred where they exist.
How daylight saving transitions are found
Transition dates are discovered, not assumed. Hard-coding a rule such as "the last Sunday in March" would be wrong for most of the world — the southern hemisphere runs its seasons in reverse, several countries have abandoned seasonal clock changes entirely, and others have moved their dates in recent years.
Instead we sample a zone's offset once per day for the next 400 days. When the offset changes between two consecutive samples, we binary-search that day down to the minute to find the exact transition instant. Whatever the IANA database says a zone does, this finds it — including zones that change more than twice a year, and zones that never change at all.
| Behaviour | Example | How it is detected |
|---|---|---|
| Standard northern DST | London, New York | Two transitions found per year |
| Reversed southern DST | Sydney, Auckland | Two transitions, forward in spring — their spring |
| No seasonal change | Tokyo, Dubai, Mumbai | No transitions found in 400 days |
| Abolished DST | Istanbul, Moscow, São Paulo | No transitions found; a fixed offset is reported |
| Half-hour offsets | Mumbai, Kathmandu | Offsets are tracked in minutes, not hours |
The working-hours model
Deciding when a meeting is reasonable requires a definition of "working hours". Ours is deliberately simple and stated openly, because any such model is an assumption rather than a fact:
| Band | Local hours | Treated as |
|---|---|---|
| Asleep | 00:00 – 05:59 | Unavailable |
| Early morning | 06:00 – 08:59 | Available, not ideal |
| Working hours | 09:00 – 17:59 | Ideal |
| Evening | 18:00 – 20:59 | Available, not ideal |
| Late night | 21:00 – 23:59 | Unavailable |
In the interactive grid these bands are editable — if your team starts at 07:00 or works late, you can change them and the overlap recalculates. The generated time difference pages use the defaults above, since they have no way to know your team's hours.
How the overlap window is chosen
For each of the 24 UTC hours, we compute the local hour in every city and classify it using the bands above. The result falls into one of three cases:
- Full overlap — every city is inside working hours. These are the green columns, and any of them is a good meeting time.
- Partial overlap — every city is at least awake, but at least one is in the early morning or evening. Workable, with someone slightly inconvenienced.
- No overlap — at every hour of the day, somebody is asleep.
In the third case we score every hour and recommend the least-bad one. Each city contributes points according to its local band, and the hour with the highest total wins:
working hours 3 points
early morning 2 points
evening 2 points
late night 0.5 points
asleep 0 pointsThe weighting encodes a judgement: an early start or a late finish is a real cost but a manageable one, whereas waking someone at 02:00 is not a scheduling option. Because working hours score higher than the awake-but-awkward bands, the recommendation favours slots that put the largest number of people at their desks rather than merely conscious.
What these calculations do not account for
The overlap model is about clocks, and clocks are only part of scheduling. Specifically:
Working weeks differ. The model treats every day the same. It does not know that the UAE works a half-day Friday, or that a public holiday has emptied one office entirely.
Cultural norms differ. A 17:00 meeting is unremarkable in Madrid and unwelcome in Berlin. The clock cannot tell you this; the city pages note it where it matters.
Lunch is not modelled. Midday is treated as ordinary working time, which is a poor assumption in southern Europe and much of Latin America.
Generated pages are a snapshot. The time difference pages are computed at build time and state the date they were generated. Between builds, a clock change in either city will make the hour-by-hour table shift by an hour. The transition dates are always listed on the page so you can see when that happens, and the interactive grid is always live.
Individual schedules vary. The model describes a conventional office day. It cannot know that your colleague in Bangalore always takes the late call, or that someone works a compressed week.
How this is kept current
The timezone rules themselves need no maintenance from us — they arrive with browser and OS updates. What we do maintain:
- The generated reference pages are rebuilt with each deployment, so their offsets, transition dates and overlap tables reflect the IANA data at build time.
- The city list is expanded when readers ask for a city that is missing. Requests are welcome.
- The guides in our blog carry a published and a last-updated date, and are revised when the underlying rules change — several countries have altered or abolished daylight saving in recent years, which invalidates advice written before the change.
- Corrections are treated as bugs. If a figure on this site disagrees with your calendar, we want to know — tell us the two cities and the date, and we will investigate.
Verifying it yourself
Every figure here is reproducible in a browser console on any machine, with no dependency on this site:
// What time is it in Mumbai right now?
new Date().toLocaleString('en-GB', { timeZone: 'Asia/Kolkata' })
// What is Sydney's UTC offset today?
new Intl.DateTimeFormat('en-US', {
timeZone: 'Australia/Sydney', timeZoneName: 'longOffset'
}).format(new Date())If those disagree with what this site shows, the difference is a bug on our side and we would like to hear about it.