Applies to: Two incident or programme timestamps fall inside the repeated hour.
The useful distinctions
- Repeated local times need an offset or another disambiguator.
- Clock labels alone can misorder events around a transition.
- UTC conversion provides a consistent elapsed-time comparison.
Separate display order from event order
A report that says an error ended before it began may simply have discarded the offset information. During a repeated hour, the clock can return to an earlier-looking label while time continues forward. Do not reverse the incident chronology merely to make the visible numbers increase. Recover the complete timestamps first. The missing context may be in an export, an original announcement or a system record that includes the offset.
Explain the result in ordinary minutes
Once both instants are resolved, report the elapsed interval plainly. Keep the local readings alongside it so support can understand why the first calculation looked strange. This is more useful than replacing every timestamp with a guessed constant adjustment. If the original data cannot distinguish the two occurrences, say that the duration is unresolved. A mathematically neat answer based on an assumed occurrence remains a guess.
Hypothetical worked example
An invented incident in America/New_York begins at 01:45−04:00 on 1 November 2026 and ends at 01:15−05:00. The checked IANA 2026f instants are 05:45 and 06:15 UTC, so the interval is thirty minutes. Bare wall-clock subtraction suggests minus thirty minutes. The viewer keeps the original labels, adds the UTC equivalents and avoids claiming either a negative outage or an unexplained ninety-minute correction.
A focused way to proceed
- Keep the date and offset beside each clock label.
- Order the records by their UTC instants.
- State the elapsed interval and retain the unusual local labels as evidence.
When to stop or ask for help
If offsets were not recorded, request a disambiguated timestamp before calculating the incident duration.