Each column is one fixed offset from UTC, from GMT−12 to GMT+14, recalculated every second from your device clock. The +1 and −1 markers show where the date has already rolled over.
Runs locally in your browserOne column for each whole hour of offset from UTC, GMT−12 through GMT+14: 27 clocks on a single screen, recalculated every second from your own device clock. A cell is the device time plus its offset, so the number in a column is the wall clock at that offset right now.
The columns carry offsets rather than city names on purpose: a city name would be wrong for half the year wherever daylight saving applies. The top row repeats your device's own time and date, and that is the reference every other column is measured against.
Every cell is a fixed offset from UTC — the device clock plus or minus a whole number of hours. That is all the GMT label means: GMT+5 runs five hours ahead of UTC the year round, whatever the date or the season. The table therefore stays correct on the weekends when much of the world moves its clocks, because the arithmetic behind each column never changes.
What a column does not do is name a zone. Berlin sits in the GMT+1 column in winter and the GMT+2 column in summer; New York moves between GMT−5 and GMT−4 on the same dates. A column shows where the clock reads that offset, not where a particular city is on a particular day.
Half-hour and 45-minute zones have no column here: India runs on UTC+5:30, Nepal on UTC+5:45 and Newfoundland on UTC−3:30 during its standard time. On a grid of whole hours those places fall between two columns and never get a line of their own.
The grid spans −12 to +14 because that is the full range of whole-hour offsets in use: Baker Island at −12, Kiritimati at +14. When a time has to be exact for one of the missing offsets, use a converter that carries IANA zone rules — a table of fixed offsets cannot answer for a named region.
The head of the table is your own machine: its time, and its date in the browser's locale. The +1 and −1 markers under a clock compare that offset's date against this row — on a device in Shanghai at 04:38 on 17 September, GMT−12 through GMT+3 were still on the previous day while GMT+4 had already crossed midnight.
All 27 offset fields are read-only: the page writes the time into them, and a stray click cannot overwrite a running clock. Nothing on the page takes input either — it is this one table, and it submits nowhere.
Every column is derived in the page by its own script from values the browser already holds — the device clock and the offset — so no request is involved in moving the clocks. Switch the browser to offline after the page has loaded and all 27 columns keep ticking.
Two things decide how accurate the result is, and both sit with you: the device clock every column is derived from, and the browser's language, which formats the date in the top row. A device clock that is a few minutes out puts every column out by the same minutes.