Time drift and event correlation

Use synthetic timestamps to distinguish clock drift from delivery delay. Compare device time, receipt time and the expected event order.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Offline research and planning only; product or deployment acceptance belongs to separately governed environment validation.

Verification and testing

Overview#

Lab class: Offline synthetic timeline fixture

Fixture design#

Create synthetic door, camera, alarm, API, broker and recorder events containing occurrence time, ingestion time, offset/timezone, source clock status, sequence and correlation ID. Include one clock 45 seconds fast, a device reboot/sequence reset, a duplicated delayed event and an ingestion backlog.

Procedure#

1. Preserve every original timestamp and offset; don't overwrite with UTC conversion.
2. Normalise display to UTC while retaining source values.
3. Calculate apparent offset between sources only where a common event/correlation makes comparison defensible.
4. Use sequence and causation to order events when clocks disagree.
5. Mark uncertainty caused by drift, reboot, capture delay, queueing and missing synchronisation status.
6. Produce a timeline with separate occurred, observed/received and processed axes.
7. Explain which conclusions remain unsupported.

Expected learning#

Authenticated NTP protects aspects of time exchange but doesn't guarantee the upstream time is correct. Wall clock order alone can't prove causation. Video overlay time, file/container time and VMS event time may come from different clocks.

Evidence checklist#

• Fixture provenance, digest, source clocks, time zones/offsets, and sequence scopes recorded
• Original timestamps preserved alongside normalised UTC display values
• Occurrence, observation/receive, ingestion, and processing times kept separate
• Drift, reboot/reset, duplication, delay, backlog, and missing synchronisation state represented
• Apparent offsets calculated only where a defensible common event exists
• Sequence and causal evidence used without treating wall clock order as proof
• Timeline conclusions state uncertainty and unsupported inferences explicitly

Sources#

• RFC 5905 NTPv4, accessed 25 August 2026.
• RFC 8915 Network Time Security, accessed 25 August 2026.

Related pages#

• Logging, time, and evidence integrity
• Timestamp normalisation example

Section overview · Wiki home