A camera clip, access event and radar track can describe the same incident yet appear in the wrong order when their clocks or timestamp meanings differ. Time synchronization needs a source, a monitored quality state and a test of the complete evidence chain from capture to export.
Table of Contents
Which timestamp describes the event?
Capture time, device event time, platform receipt time and export time describe different points in the information chain. Correlation becomes unreliable when one is silently substituted for another.
Define the timestamp origin for every source. A camera’s visible overlay may be useful for review but should not be assumed to match the metadata used by the recorder. A sensor may timestamp an event when a rule completes rather than when the physical activity begins.
Axis’s interface documentation describes time-synchronization status and configuration. Availability varies by device; confirm the features of the actual model instead of assuming a common interface implies identical clock behavior.
How should the time source be selected?
Choose an authoritative source and a supported synchronization design with the infrastructure team. Record the permitted time servers, network paths, authentication where supported and how source health is monitored.
Network Time Protocol (NTP) is common, but choosing a protocol does not establish a particular accuracy. Device implementation, polling, network behavior and holdover all matter. Precision Time Protocol (PTP) can serve different timing needs when the devices and network support the complete design.
Use an unambiguous stored time basis, commonly UTC, and treat local time-zone display as a separate concern. Test daylight-saving transitions and exports; a repeated local hour should not create ambiguous evidence identifiers.
Measure the offset through the evidence path
Use a controlled common event visible or observable to the relevant systems, with a sufficiently characterized reference for the required tolerance. Compare the original records, recorder playback, platform event and exported file.
| Layer | Check | Evidence to keep |
|---|---|---|
| Time service | Source health and reachability | Server and monitoring status |
| Camera or sensor | Clock offset and timestamp meaning | Configuration and event record |
| Recorder | Treatment of incoming timestamps | Playback and recording metadata |
| Integration platform | Capture versus arrival time | Correlated event export |
| Evidence package | Time basis survives export | Original file and export settings |
Define a task-specific tolerance before testing. A coarse incident timeline and a tightly coupled sensor handoff may need different timing performance.
What happens during loss and recovery?
Test time-source loss in an approved test environment or maintenance window. Observe how the device reports synchronization loss, how its clock evolves and what happens when service returns.
A recovery may adjust time gradually or introduce a step, depending on the system. Check for duplicate timestamps, apparent event reordering, recording gaps and incorrect duration calculations. Preserve the affected interval and administrative logs.
A network outage also delays receipt without necessarily changing capture time. Do not “fix” that delay by rewriting all device timestamps to arrival time. Retain enough provenance to reconstruct the difference.
Keep clock changes visible to operators
Include synchronization health in the operational view and identify which correlation functions depend on it. An unavailable or uncertain time state should be distinguishable from a normally synchronized source.
Review timing after firmware updates, recorder replacement and changes to network policy. The integration checklist covers the broader event contract, while the counter-UAS evidence workflow shows why ordering and provenance matter to incident review.
Keep the time architecture, measured offsets and sample exports with the system configuration. Later investigators can then relate the displayed time to capture, storage and export behavior.
FAQs
Does showing the same clock time prove cameras are synchronized?
No. The displayed precision may hide offset, and overlays may use a different time basis from metadata. Verify a common event across the actual evidence paths.
Is receipt time equivalent to capture time?
No. Network and processing delays separate them. Retain both fields where available and state which timestamp drives correlation.
What should happen if the time source is lost?
The system should expose synchronization status and clock quality, retain the affected interval and follow a tested recovery policy. It should not silently imply normal timing accuracy.
