Why a world clock never stores an offset, and why India is the zone that catches the shortcuts
The tempting way to build a world clock is a table of cities and their offsets from UTC: New York is minus five, London is zero, India is plus five and a half. It is wrong for most of the world for part of every year. Around seventy countries move their clocks for summer, they do it on different dates, and the southern hemisphere does it in the opposite season, so the gap between New York and Sydney is fifteen hours in July and sixteen in January, and for a few weeks in March and again in October and November it is a figure neither table row predicts. The rules also change by law, sometimes with weeks of notice. The only source that keeps up is the IANA time zone database, which your operating system and browser already carry and update. So this page never stores an offset. Every number on it is asked of Intl.DateTimeFormat at the instant being shown: what does a wall clock in this zone read right now, or at the moment you are planning. The offset is then the difference between that reading and UTC, worked out fresh each time, which is why a clock here changes on the correct night without the page knowing the date of any change.
Going the other way is harder. Turning "7 in the evening in Mumbai on Tuesday" into an instant means knowing the offset that applies at an instant you have not found yet. The page guesses the instant using the offset at the naive reading, then corrects it once using the offset at the guess, and that settles every case except the two that daylight saving itself creates. A time skipped by the spring change, such as half past two on the night New York jumps from two to three, has no instant at all, and the answer lands an hour to one side. A time repeated by the autumn change has two, and one of them is chosen. Both outcomes are what a person scheduling a call at that hour would accept, and the tests pin each of them down on real 2026 dates. Moving to the next day is done on the calendar rather than by adding twenty four hours, because on the night the clocks change a day is twenty three or twenty five hours long, and 9 in the morning plus twenty four hours is not 9 in the morning.
India is the zone that exposes shortcuts. It is five hours and thirty minutes ahead of UTC, Nepal is five forty five, and parts of Australia and Canada sit on half hours too. Any design that assumes zones differ by whole hours draws the wrong strip for more than a billion people. Here each row of hours is computed by asking what that zone reads at each hour of the home day, so a Delhi row seen from New York starts at half past, and the row says so in words instead of rounding the minutes away. The same care decides the day. Whether another city is on yesterday or tomorrow is read from the calendar dates the two zones show at that instant, not inferred from the size of the offset, which is how the Auckland clock comes out right on New Year’s Eve.
Zone names turned out to need the same treatment. IANA renamed Calcutta to Kolkata, Kiev to Kyiv and Saigon to Ho Chi Minh, keeping the old names as aliases, and browsers do not agree on which one to report. Chrome resolves Asia/Kolkata back to Asia/Calcutta, while Firefox does the reverse, so an Indian laptop running Chrome describes its own zone with a name the city dropped decades ago. Comparing zones as strings would put India on the list twice, once under each name. Every zone is therefore reduced to a key, by letting the engine fold its own aliases and then mapping the renames it still reports to their current names, and the list, the search and the share link are all built on that key.
Nothing here asks where you are. Your device is set to a time zone and the browser reports it, so the first clock is yours with no location prompt and no lookup of your connection. The curated cities answer most searches by the names people type, including countries and abbreviations, and Intl.supportedValuesOf supplies the full list of around four hundred zones for everything else. That call is newer than the rest of the page, so the tool declares it as a preferred capability: without it the curated cities still work and the page says plainly that search is narrower. A share link carries the list of zones in the address fragment, which browsers never send to a server, and whatever arrives in one is checked against the zones this browser accepts before a single clock is drawn.