The hour that does not exist: daylight saving in 418 time zones

On Sunday 8 March 2026 the clocks in New York went from 01:59 straight to 03:00. Anything you scheduled for 02:30 that morning was scheduled for a time that never happened. On Sunday 1 November they went from 01:59 back to 01:00, so 01:30 happened twice, an hour apart. Software still has to turn both of those into a single number, and it very rarely tells you which choice it made.

This is usually explained with the New York example and left there. We wanted the wider picture, so we measured it: every time zone that one current browser knows about, across the whole of 2026, and then what the browser's own date constructor does with the two awkward cases.

How we measured

We asked Chrome 153 for its full list of IANA time zones — 418 of them — and scanned each one from 1 January to 31 December 2026 in six-hour steps, reading the UTC offset every time. Whenever the offset changed we narrowed the moment down to the second. The data is the time zone database bundled with that browser on 25 September 2026; governments change these rules with little warning, so treat every number below as a snapshot rather than a law.

Who changes their clocks in 2026

Two of those are not what the phrase "daylight saving" suggests. Morocco's Africa/Casablanca and Africa/El_Aaiun spend most of the year one hour ahead of UTC and drop back to it for Ramadan: in our scan the offset falls on 15 February and rises again on 22 March. And a half-hour change means the repeated or skipped stretch is thirty minutes long, not sixty.

Four days hold almost everything

The 260 changes fall on 17 different days of the year, but four of them account for 220:

That is 85% of all changes on four days. It also means the two great transitions are three weeks apart in spring and one week apart in autumn: for a few weeks each year the gap between London and New York is not five hours but four, and a meeting that was correct in February is an hour off in March if it was stored the wrong way.

Not always a Sunday

Measured by the local day the clock jumps, 249 of the 260 changes are on a Sunday. The other eleven are on a Friday or a Saturday: Cairo on Friday 24 April and Friday 30 October, Jerusalem on Friday 27 March, Gaza and Hebron on Saturday 28 March and Saturday 24 October, Easter Island on the Saturdays of 4 April and 5 September, and two Greenland zones on Saturday 28 March. A rule such as "the change is always on a Sunday" is right about nine times in ten and wrong for entire countries.

What a program does with a time that does not exist

Then the awkward part. We set the browser's time zone in turn to four places and passed a local time inside each skipped or repeated stretch to the ordinary new Date(year, month, day, hour, minute) constructor, then read back the UTC instant it produced.

The rule was the same in all eight cases: a skipped time is read using the offset from before the change, which pushes it forward onto the clock time an hour (or thirty minutes) later, and a repeated time is read as its first occurrence. That matches what the JavaScript specification prescribes, and it is a reasonable default. What matters is that nothing in the result says a choice was made. The 02:30 you typed comes back as an instant that, displayed in New York, reads 03:30. The 01:30 that could have been either of two instants comes back as one of them.

We only tested Chrome. Other languages have their own rules for the same case — Python's datetime, for instance, carries a separate fold flag to say which occurrence of a repeated time you mean (PEP 495) — which is exactly why two programs converting the same local time can disagree by an hour.

What to do about it

• Store the instant, not the wall clock. A Unix timestamp or a UTC time has no skipped or repeated hours. Convert to local time only for display.
• Store the zone name, not the offset. America/New_York knows about the change; -05:00 does not, and is wrong for half the year.
• For future events, store the local time and the zone. A meeting at 09:00 in Paris in November 2027 should stay at 09:00 if the rules change. Turn it into a timestamp as late as you can.
• Never schedule inside the change window. If a job must run at 02:30 local, decide in advance whether it runs zero, one or two times on the two change days.
• When you accept a local time, accept an offset with it where you can. 2026-11-01 01:30 -05:00 is one moment. 2026-11-01 01:30 is two.

Our Unix timestamp converter does the last one for you: type a date in a chosen zone and it tells you when that local time was skipped, or lists both timestamps when it happened twice. Timestamps go the other way too, with the offset that applied at that moment rather than today's.

Limits of this measurement

One browser, one snapshot of the time zone database, one year. The counts will differ in other years and in other software, because governments add, drop and move changes — Morocco's Ramadan rule and Egypt's return to daylight saving are recent examples. The scan lists the zones as the browser reports them, which includes a few older aliases, so 418 is the browser's count and not an official one. We will re-run it when the rules change.