daylight savingalarmstime zonestzdatafield log

I Ran 24 Clock Changes Through the tz Database to See Which Minutes Disappear

An alarm set inside a skipped hour fires late or at an adjusted time; one set inside a repeated hour fires once. Sydney changes Sunday 4 October 2026.

By the DontSnooze Team · · 6 min read
In this article10 sections

Sydney’s clocks jump from 02:00 to 03:00 on Sunday 4 October 2026, and the 60 minutes of 02:00-02:59 never happen. An alarm set inside that hour has no valid instant — it fires late or at an adjusted time. When clocks go back, one hour of wall-clock time occurs twice, and a well-behaved alarm fires once, on the first pass. London’s skipped hour is 01:00-01:59, an hour earlier than everyone else’s.

I wanted that as computed output rather than as a fact I’d repeated from memory, so I wrote a script against the system tz database (tzdata 2026b, Python 3.11 zoneinfo) and ran it. Everything below is that output.

Which minutes vanish, and which happen twice?

The script walks UTC minute by minute from 2026-01-01 to 2027-12-31 and records every moment the UTC offset changes. In the six zones tabulated here, four changes each, 24 transitions, all exactly 60 minutes. Lord Howe Island, covered in the questions below, is the exception.

ZoneLocal date (Sunday)UTC instantWall clock jumpsEffect
America/New_York2026-03-0807:0002:00 to 03:0002:00-02:59 skipped
America/Los_Angeles2026-03-0810:0002:00 to 03:0002:00-02:59 skipped
Europe/London2026-03-2901:0001:00 to 02:0001:00-01:59 skipped
Europe/Berlin2026-03-2901:0002:00 to 03:0002:00-02:59 skipped
Pacific/Auckland2026-04-0514:00 (Sat)03:00 to 02:0002:00-02:59 twice
Australia/Sydney2026-04-0516:00 (Sat)03:00 to 02:0002:00-02:59 twice
Pacific/Auckland2026-09-2714:00 (Sat)02:00 to 03:0002:00-02:59 skipped
Australia/Sydney2026-10-0416:00 (Sat)02:00 to 03:0002:00-02:59 skipped
Europe/London2026-10-2501:0002:00 to 01:0001:00-01:59 twice
Europe/Berlin2026-10-2501:0003:00 to 02:0002:00-02:59 twice
America/New_York2026-11-0106:0002:00 to 01:0001:00-01:59 twice
America/Los_Angeles2026-11-0109:0002:00 to 01:0001:00-01:59 twice
America/New_York2027-03-1407:0002:00 to 03:0002:00-02:59 skipped
America/Los_Angeles2027-03-1410:0002:00 to 03:0002:00-02:59 skipped
Europe/London2027-03-2801:0001:00 to 02:0001:00-01:59 skipped
Europe/Berlin2027-03-2801:0002:00 to 03:0002:00-02:59 skipped
Pacific/Auckland2027-04-0414:00 (Sat)03:00 to 02:0002:00-02:59 twice
Australia/Sydney2027-04-0416:00 (Sat)03:00 to 02:0002:00-02:59 twice
Pacific/Auckland2027-09-2614:00 (Sat)02:00 to 03:0002:00-02:59 skipped
Australia/Sydney2027-10-0316:00 (Sat)02:00 to 03:0002:00-02:59 skipped
Europe/London2027-10-3101:0002:00 to 01:0001:00-01:59 twice
Europe/Berlin2027-10-3101:0003:00 to 02:0002:00-02:59 twice
America/New_York2027-11-0706:0002:00 to 01:0001:00-01:59 twice
America/Los_Angeles2027-11-0709:0002:00 to 01:0001:00-01:59 twice

Europe changes at one UTC instant for every member country, while the US changes at 02:00 local in each zone, so the transatlantic offset is wrong for a week or three each time.

What does “schedule it, then add 24 hours” actually do?

This is the core of the script. The naive version fires once, then adds 24 elapsed hours forever. The other resolves the wall-clock time again each day.

from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo
U = timezone.utc
def naive(zone, day, t, n=3):
    f = datetime.combine(day, t, ZoneInfo(zone)).astimezone(U)   # day before
    for _ in range(n):
        yield f.astimezone(ZoneInfo(zone)).strftime("%H:%M")
        f += timedelta(hours=24)                                 # elapsed 24h
def wall(zone, day, t, fold):
    d = datetime.combine(day, t, ZoneInfo(zone)).replace(fold=fold)
    return d.astimezone(U).astimezone(ZoneInfo(zone)).strftime("%H:%M")

I fed both an alarm inside each affected hour and printed the local fire time for the day before the change, the day of, and the day after.

Zone, changeAlarmNaive, 3 dayswall() fold=0wall() fold=1
Sydney, 2026-10-0402:3002:30, 03:30, 03:3003:3001:30
New York, 2027-03-1402:3002:30, 03:30, 03:3003:3001:30
Berlin, 2027-03-2802:3002:30, 03:30, 03:3003:3001:30
New York, 2026-11-0101:3001:30, 01:30, 00:3001:3001:30
London, 2026-10-2501:3001:30, 01:30, 00:3001:3001:30
Berlin, 2026-10-2502:3002:30, 02:30, 01:3002:3002:30

What surprised me

The naive spring result is not a one-off miss. It fires at 03:30 on the change day and keeps firing at 03:30 every day after, an hour late until someone edits it. The naive autumn result is worse for being invisible on the day: it fires correctly on the change day, then 00:30 the next, an hour early, permanently.

Then there is fold. On fall-back rows, fold=0 and fold=1 print the same wall time, because both are real; they differ by 60 minutes of elapsed time (05:30 UTC versus 06:30 UTC for New York). On spring rows, the 02:30 does not exist, and PEP 495 says fold=0 interprets it with the pre-change offset (giving 03:30) and fold=1 with the post-change offset (giving 01:30, before the gap). The second one fires early, which for an alarm is the dangerous direction. Neither equals 03:00, the first instant that actually exists after the gap, and that is the value I would pick if choosing.

For the correct implementation, store the intent as local time plus an IANA name, resolve it fresh each day, take the earliest valid instant, and decide the gap policy on purpose. The post on offset drift covers the cached-offset variant of the same bug, and the dialogue on how a phone gets its time explains where the OS gets the tz rules it applies at arm time. An elapsed-time scheduler picks its gap behavior by accident rather than by decision.1

Questions the table raises

Which zones shift by 30 minutes instead of an hour?

Lord Howe Island (Australia/Lord_Howe) is the one in this run. On 2026-10-04 its clocks go from 02:00 to 02:30, skipping only 02:00-02:29, and on 2026-04-05 they go from 02:00 back to 01:30, so 01:30-01:59 happens twice. Both repeat in 2027, on 2027-04-04 and 2027-10-03. Code that assumes every change is exactly 60 minutes breaks there.

Which large zones skip nothing in 2026 and 2027?

The same scan found zero offset changes in Asia/Tokyo, Asia/Kolkata, Europe/Istanbul, Europe/Moscow, America/Mexico_City and America/Sao_Paulo across both years.

Why is New York to Berlin only 5 hours apart for a week?

Europe changes at 01:00 UTC on 2026-10-25, while the US waits until 2026-11-01. Between those dates the gap is 5 hours instead of 6. The mismatch is longer in spring, three weeks in 2026 (2026-03-08 to 2026-03-29) and two in 2027 (2027-03-14 to 2027-03-28), because the US moves first.

Does the same wall-clock time ever occur twice with different UTC offsets?

Yes, on fall-back days. 01:30 in New York on 2026-11-01 happens at 05:30 UTC (UTC-4) and again at 06:30 UTC (UTC-5). A local timestamp without an offset or fold flag cannot tell them apart, so logs written in local time are ambiguous for exactly 60 minutes a year.

What this run does not cover

No alarm was run on a physical phone. The script shows what the arithmetic does; it says nothing about what Apple’s or Google’s Clock app does inside a skipped hour, so no claim is made. The case file in the account of the 2010 and 2011 iPhone alarm failures is a reminder that vendor behavior around these dates has been wrong before, and been fixed afterward. The naive and wall() tables cover whole-hour zones only; Lord Howe’s 30-minute change appears in the FAQ above, from the offset scan, and I did not run the alarm functions against it.

Footnotes

  1. The makers of this site also build DontSnooze, an iOS app that schedules alarms, and its terms say alarms are not guaranteed to fire in every circumstance. ↩

Posted in daylight saving alarms time zones tzdata field log

Keep reading