The missing spring hour and the repeated autumn hour

Some local clock readings identify no instant; others identify two.

WhatTimeIsIt Published 11 October 2026

Why a local reading can fail

When a clock moves forward, it skips a range of local readings. When it moves backward, a range happens twice. The exact date, size of the change and transition hour depend on the location’s rules. This means a date and local hour are not always enough to identify one instant. The problem is most visible in overnight appointments and logs, but it is a general consequence of changing UTC offsets.

A concrete autumn example

In London on 25 October 2026, the clock moves from 02:00 BST back to 01:00 GMT. A local reading of 01:30 therefore happens once with UTC+01:00 and again with UTC+00:00. The two appointments would be an hour apart in elapsed time. Writing the offset or an explicit UTC timestamp distinguishes them. The UK autumn briefing gives the scheduled change and its practical implications.

A concrete spring example

Under the US seasonal rule, a participating location moves from 02:00 to 03:00 in spring. A local reading inside the skipped hour does not occur on that transition date. Software may reject such input or interpret it according to a documented rule; users should not assume every application behaves identically. For an important appointment, choose an unambiguous hour or ask the organizer to confirm the resulting instant in the actual calendar system.

Handle ambiguity explicitly

When reporting a problem, include the city, full date, local reading and expected offset. Preserve original timestamps in logs and compare their UTC instants before deciding that two entries are duplicates. For event announcements, avoid transition windows when possible and test exported invitations when they cannot be avoided. Our event-time guide shows what to publish, while the timestamp guide explains how one instant can have several local representations.