The Missing Hour and the Repeated Hour: What the Time Zone Planner Does on the Four 2026 Clock-Change Dates

I work on OnePassApps, the team behind app.onepassapps.com, so this is our own app measured on our own build. Three of our earlier posts on the Time Zone Planner covered the two-place plan, the reference-place swap and the eight-place cap. Each of them stopped short of one thing: what the app does on the four dates in 2026 when the clocks actually change. Our Telegraph post on the reference-place swap says so in its own limits - "I did not change the date away from 6 November 2026, so no claim is made about a daylight-saving transition." This post measures it. You can try it on the Time Zone Planner, or see how it sits with the rest of the suite in the app guides. The plan throughout is the default one: London as the reference place, New York as the second place, both working 09:00 to 17:00, and a one-hour meeting. Two of the panel's own lines set the rules: "Offsets come from your browser's own time zone data." and "Hours are checked at both ends of the meeting." The four dates Each row is what the panel printed with the meeting at 15:00, and each offset was recomputed outside the browser against the same IANA rules. Date What changed London New York Shared hours 2026-03-07 the day before GMT · UTC GMT-5 · UTC-5 14:00–17:00 London 2026-03-08 US clocks go forward GMT · UTC GMT-4 · UTC-4 13:00–17:00 London 2026-03-29 UK clocks go forward BST · UTC+1 GMT-4 · UTC-4 14:00–17:00 London 2026-10-25 UK clocks go back GMT · UTC GMT-4 · UTC-4 13:00–17:00 London 2026-11-01 US clocks go back GMT · UTC GMT-5 · UTC-5 14:00–17:00 London 2026-11-07 a control date GMT · UTC GMT-5 · UTC-5 14:00–17:00 London The shared-hours line moves by an hour and moves back again, because the two zones change on different dates: the overlap opens an hour earlier when New York springs forward, and an hour later when New York falls back. The line itself reads "Shared working hours: 13:00–17:00 London" on 2026-03-08 and "Shared working hours: 14:00–17:00 London" on 2026-03-07. The label follows the meeting, not the date On 2026-03-08 the New York card reads "America/New_York · GMT-4 · UTC-4" with the meeting at 15:00, and the meeting row shows 11:00–12:00 in New York. Move the meeting to 01:30 on that same date and the same place reads "America/New_York · GMT-5 · UTC-5", with the row showing 20:30–21:30 on 2026-03-07 (-1 day). The reason is the instant: 01:30 in London is 01:30 UTC, and New York had not yet changed at that moment - it changes at 07:00 UTC that day. A date does not have one offset on a clock-change day; an instant does. The shared-hours line does not follow the meeting, though. It stayed at 13:00–17:00 London for both meetings on 2026-03-08, because it is worked out from the two working windows and the offset in force when each window opens. The hour that is missing On 2026-03-29 the clocks in London go forward at 01:00 GMT, so the local times 01:00 to 01:59 never happen on that date. A minute-by-minute scan of the UTC timeline confirms it: local hour 01 has zero real instants that day. Enter a meeting at 01:30 on that date and the London row reads 02:30–03:30 BST, with New York at 21:30–22:30 on 2026-03-28 (-1 day). The exported calendar file agrees. It is 555 bytes on disk, and it carries DTSTART:20260329T013000Z with DTEND:20260329T023000Z, and unfolded, its London line reads "London: 2026-03-29 02:30–03:30 BST (UTC+1) – outside working hours", with the New York line on 2026-03-28 at GMT-4. So the 01:30 you typed never appears in London's column. The app read your 01:30 in the offset London had before the change, and then showed the result in the offset London has after it. The file records the instant, not your intention. The hour that repeats On 2026-10-25 the clocks in London go back at 02:00 BST, so local hour 01 happens twice: 120 real instants, the first at 00:00 UTC and the last at 01:59 UTC. Enter a meeting at 01:30 on that date and the London row reads 01:30–01:30, with New York at 20:30–21:30 on 2026-10-24 (-1 day). The exported file is 555 bytes and carries DTSTART:20261025T003000Z with DTEND:20261025T013000Z - one hour of real time, from 00:30 UTC to 01:30 UTC - unfolded, whose London line reads "London: 2026-10-25 01:30–01:30 BST (UTC+1) – outside working hours". An hour of real time that takes no space at all on London's clock, because the clock runs that hour twice. The app takes the first of the two 01:30s, the one still in BST. The file carries UTC instants and no VTIMEZONE block, which our earlier posts established. That matters here: a calendar client in London reading this file has to choose which of the two 01:30s on 25 October it means, and the file cannot tell it. What I did not measure One build, one browser, one signed-out session, 8 November 2026. London was the reference place throughout, with 09:00 to 17:00 windows and a one-hour meeting. I measured the four 2026 UK and US transition dates and one control date; I did not test a southern-hemisphere zone, a half-hour transition zone, or a second meeting length on a transition date. I read the two exported files off disk and did not open them in a calendar client, so I am not claiming what a client displays. The overlap arithmetic was recomputed outside the browser against the same zone rules the panel reads from, and every offset, every shared-hours line, every meeting row and both files were asserted against this run's own capture before this was published. For the parts of this app we measured earlier, see the two-place plan and the .ics file and the third place with a 45-minute offset. I work on OnePassApps, and everything above was measured on our own build in our own tab.