About wherewhen.co
wherewhen.co answers questions about time across cities: what time it is somewhere now, what a given hour becomes elsewhere, when two to four cities can meet, and — the part most tools skip — how the difference between two places changes over the course of a year.
What the site computes
Everything published here is derived, not collected. There is no editorial database of “London is 5 hours ahead of New York”; that sentence is computed at build time from the IANA time-zone database, and recomputed on every build.
The offset profile
The unit of computation is a pair of IANA zones, not a pair
of cities — many city pairs share a zone pair, and they must never disagree.
For each zone pair the site evaluates the UTC-offset difference
(offsetA − offsetB, signed minutes, so a positive value means A
is ahead) at every step across a window, and treats the result as what it
actually is: a step function.
- Window — one calendar year. 1 January to 31 December of the current year, not a rolling twelve months from today. A calendar year reads January → December the way a reader expects, and it puts the year boundary cleanly at the edge of the chart. It rolls over on 1 January; there are no per-year archive pages.
- Run-length encoding. The step function is compressed into periods — each a span of dates over which the difference held one value. Most pairs need one or two.
- The wrap merge. A period that ends on 31 December and a period that starts on 1 January with the same offset are one period, not two. Skipping this merge is the classic way to report a “change” that is only an artifact of where the window was cut, and it is the single most load-bearing step in the pipeline.
- Classification. Pairs come out as CONSTANT (one value all year), SPLIT (two substantial states), or DOMINANT (one value for at least 85% of the year, with short anomaly windows — typically the few weeks when two countries have changed their clocks on different dates). The threshold is not delicate: the distribution is strongly bimodal, and only a couple of dozen zone pairs out of thousands land anywhere near it.
Sub-hour offsets are handled throughout — nothing in the pipeline assumes whole hours. Roughly 67% of major city pairs are not constant across the year, which is why the site treats the year, not the moment, as the unit of description. The long version is here.
Live times
Clocks and converted times are computed in your own browser from its time-zone data, so they stay correct between builds and across a daylight- saving transition that happens while a page is open. The baked text on a page and the live tool read from the same offset data shipped with the build, so a page and a tool never disagree.
Where the data comes from
- IANA Time Zone Database (tzdata)
- Every offset, transition and daylight-saving rule. This build was compiled against tzdata 2026b. The database is in the public domain; see iana.org/time-zones.
- GeoNames
- City names, countries, coordinates and populations — the 27,000+ city directory behind the converter and planner. Used under CC BY 4.0, attributed to GeoNames here and in the footer of every page.
- Nothing else
- No scraped content, no third-party time API, no generated prose about places. If a sentence on this site states a number, a program computed it from the two sources above.
How the numbers are tested
Time-zone arithmetic fails in specific, well-known ways: the hour that does not exist in a spring-forward gap, the hour that happens twice in a fall-back, offsets that are not whole hours, southern-hemisphere DST running the other way, zones that changed rules recently, and the date line.
So the site is gated against a public corpus of exactly those cases: tz-edge-cases — 68 cases, published as its own repository under CC0 so anyone can run it against their own implementation.
The corpus runs before any page is generated, on every build. 64 cases concern past instants and can never legitimately change — a mismatch there fails the build and nothing is published. The remaining 4 concern future instants subject to government decree, or pre-1970 data where the tz database itself gives no stability guarantee; those are reported, not fatal. The corpus's expected values are pinned to tzdata 2026c.
Privacy
No accounts, no cookies, no analytics script and no third-party trackers — you can confirm all of that by reading the source of any page. The pages are static files; the only network requests they make are for the site's own city and offset data. The web server keeps standard access logs. Your location is never requested — the local time shown on the homepage comes from your browser's own time-zone setting and is never sent anywhere.
Scope and honesty about limits
- City pages exist for 78 cities, chosen by demand, and the set grows in small batches. The converter and planner accept any of the 27,000+ cities in the directory, whether or not it has a page.
- Future dates are only as reliable as the tz database, which encodes current law. Governments change daylight-saving rules — sometimes with weeks of notice — and the site rebuilds regularly to pick those changes up, but a decree issued after the last build will not be reflected until the next one.
- Historical answers before 1970 are outside what the site publishes; the tz database does not guarantee them.
Contact
Corrections, especially about a city or a rule the site gets wrong, are genuinely welcome — write to [email protected]. Issues with the edge-case corpus itself belong on the repository.