Applies to: An incident is discussed across different days or timezones.
The useful distinctions
- A message timestamp identifies that message’s instant.
- A later reply does not establish when the original issue began or ended.
- A full date and offset make cross-location chronology easier to compare.
Name the event attached to each time
A timestamp is only useful when the report says what happened at that instant. The first observation, the first message, the support response and the successful recheck can all occur at different times. Combining them into one date field loses that sequence. Write a short label beside each time. If the viewer remembers only when they first noticed the issue, do not present that as the exact moment it began.
Avoid inventing a continuous failure
A reply on the next day does not prove that the problem lasted overnight. Likewise, a successful check after a reply does not establish exactly when recovery happened. Record the last failed observation and the first successful observation as bounded evidence. This gives support a useful investigation window without turning an unobserved interval into a confident outage claim or confusing response speed with programme availability.
Hypothetical worked example
A fictional viewer notices a guide mismatch at 18:00 UTC on 8 November 2026 and receives a reply at 09:00 UTC on 9 November. Their note has two entries: issue observed and reply received. They do not describe a fifteen-hour failure unless observations support that duration. If the next check succeeds at 09:10, they add that result while leaving the actual recovery time unresolved between the last failed and first successful checks.
A focused way to proceed
- Write the incident observation time separately.
- Keep the support-message time in the conversation history.
- Mark an unknown start or recovery time as unknown.
When to stop or ask for help
Supply a labelled chronology and distinguish observed times from estimated or unknown incident boundaries.