Applies to: A programme or incident is recorded during a repeated local hour without its offset or occurrence context.
The useful distinctions
- A backward transition can repeat a local clock value.
- The offset or equivalent UTC instant can distinguish the occurrences.
- A local time without that context can remain ambiguous.
Keep both possibilities visible
During a backward clock transition, a local hour can occur twice. A report that includes the location and date but omits the occurrence or offset may still be incomplete. Do not assume the earlier or later interpretation merely because it is the one a particular interface selects by default. Preserve the original value and seek enough context to identify one actual instant before comparing programme starts or incident records.
Use an unambiguous anchor
An equivalent UTC time, explicit offset or reliable before-and-after event context can clarify the intended occurrence. Keep the resolution with the record so another person does not later reinterpret the same clock label. This matters when two reports appear to contradict each other but may simply refer to different occurrences of the repeated hour. The task is to disambiguate the observation, not to declare either observer’s clock defective.
Hypothetical worked example
The checked IANA examples for America/New_York on 1 November 2026 include local 01:30 with offset −04:00 at 05:30 UTC, and local 01:30 with offset −05:00 at 06:30 UTC. A fictional incident note saying only “01:30” cannot choose between them. Asking which offset or UTC instant was intended resolves a one-hour ambiguity without moving the entire programme guide.
A focused way to proceed
- Keep the local date and named location.
- Ask for the stated offset or another unambiguous event reference.
- Preserve which occurrence was intended rather than choosing by guesswork.
When to stop or ask for help
Add the offset or equivalent instant that identifies the intended occurrence of the repeated hour.