Probing beats a stored table
The obvious way to build this page would be to write the rules into it: second Sunday in March, first Sunday in November, and so on. That approach is wrong the moment any jurisdiction changes its mind, and jurisdictions change their minds regularly — dates move, regions adopt the practice or drop it, and territories switch which side of a boundary they sit on.
Instead the page asks the browser what the UTC offset is at a given instant, samples a year one week at a time, and binary searches any window where the answer changed until it has the transition to the second. Since transitions are months apart, a weekly probe cannot step over one. The data comes from the IANA time zone database the browser already carries, so it is as current as the browser is, and a zone whose rules changed in 2007 or 2022 is handled without this page knowing anything about it.
A deleted hour and a repeated hour are different problems
When the clock jumps forward, an hour of local time ceases to exist. There is no instant that reads 02:30 that morning. A timestamp written as 02:30 is not merely inconvenient, it is not a time — and every piece of software has to choose what to do with it. Some shift it forward, some backward, some throw. A job scheduled inside that hour usually does not run.
When the clock jumps back, an hour repeats. 01:30 happens twice, an hour apart, and a local timestamp of 01:30 names two different instants. Nothing in the string distinguishes them; only the offset does, which is why log formats that record an offset or use UTC survive that morning and formats that record bare local time do not. A job scheduled inside the repeated hour may run twice.
The table names which hour is affected in each direction, so you can check a schedule against it before the morning rather than after.
What breaks, concretely
Duration arithmetic is first. A shift that starts at 22:00 and ends at 06:00 is eight hours on most nights and seven or nine on those two, and a timesheet that subtracts wall clock readings will not notice. Whether the pay follows the clock or the elapsed hours is an employment question with different answers in different places and different agreements, so this page will not tell you which figure to use — it tells you that the two figures differ and by how much. The datetime difference calculator shows both for a specific pair of stamps.
Scheduled jobs are second. Cron matches wall clock fields, so anything scheduled between 01:00 and 03:00 local is exposed on both mornings; the cron expression builder flags the window. Recurring calendar entries are third: an appointment pinned to a fixed UTC offset rather than to a named zone moves by an hour for participants in a zone that just switched.
The comparison table is there for the cross-zone case. Because each zone changes at the same local hour, the country does not switch at once, and for a few hours the usual gaps between zones are one hour narrower or wider than normal. Anything that assumes a fixed inter-zone gap is wrong for that window. The meeting time finder resolves the offsets for a specific date so a meeting planned across the boundary lands where you expect.
How far ahead the answers are meaningful
Past transitions are historical facts and the database records them, including the periods when the rules were different from today. Near-future transitions follow current law and are reliable enough to schedule against.
Far-future ones are projections. The database extends today's rule indefinitely because it has nothing else to extend, so a lookup for a date decades out tells you what would happen if nothing changed. Legislatures periodically consider abolishing the practice or making one setting permanent, and any such change would invalidate every projected date past its effective day. Treat a distant year as a planning estimate, not a commitment, and re-check it closer to the time — the answer is only ever as current as the time zone data on the machine asking the question.
Questions people ask
Where does the data come from?
From the IANA time zone database that ships with your browser, queried through the standard internationalisation interface. This page contains no table of rules; it samples the offset across the year and narrows down each change it finds. That means it stays correct for zones whose rules have changed, without needing to be updated itself.
Why does it say a day was 23 or 25 hours long?
Because it was. The day length column measures local midnight to the next local midnight, and on a transition day that span is an hour shorter or longer than 24. Any calculation that converts days to hours by multiplying by 24 gives the wrong answer on exactly those days.
What happens to a timestamp inside the skipped hour?
It does not correspond to any real instant, so software has to make a choice — shift it forward past the gap, shift it backward, or reject it. Different libraries choose differently. If you control the format, record the UTC offset alongside the local reading, or store UTC, and the problem disappears.
Can I trust the dates for a year far in the future?
They are projections of the current rules rather than facts. The database extends today\u2019s rule forward because it has nothing better to extend, and any legislative change would move every date after it. Use a distant year for planning and re-check nearer the time.
Why do the United States zones change at different instants?
Because each zone switches at the same local hour, and the zones are not at the same instant when their local clocks read that hour. For the few hours between the earliest and latest switch, the normal gaps between the zones are narrower or wider than usual, which is enough to move a cross-country meeting by an hour.