Two records can describe the same moment with different-looking times. Preserve the originals and establish the time reference before treating the difference as a delay.
The idea in view · Planning diagram
Keep original time and interpretation together
- Camera value
- Recorder value
- Platform value
- Source and zone
- Known offset
- Qualified sequence
Establish the reference
Have IT confirm an approved time source and the intended site time zone. Keep local operational schedules distinct from UTC incident timestamps. Avoid relying on an abbreviation such as CST that can refer to different zones.
Compare a staged event
Record the same safe visible action across relevant cameras and the incident system. Note any offset rather than silently rewriting evidence. Check whether exported clips include the zone and whether the player displays a different time.
Manage time changes
Review holiday and daylight saving boundaries for the site’s schedule. Record the configuration change and approval. Where a historical timestamp is wrong, retain the original and attach an explanation of the known offset.
Keep event time and entry time distinct
An incident can be entered after the activity occurred. Record the observed event time and the record-entry time as separate facts. If the system clock has an offset, note how it was established without rewriting the original clip. NIST’s export work and GOV.UK retrieval guidance both make time and source context relevant to usable evidence.
For operating schedules, use the site’s named time zone and check the actual transition dates that apply there. Do not rely on a familiar abbreviation across a portfolio. After an authorized time-setting change, verify fresh footage, exported playback and incident records with the same staged event. Keep historical uncertainty visible where it cannot be resolved.
Keep the time sources separate
A camera overlay, recorder index, exported filename and incident platform may show different representations of time. Identify which system produced each value and whether it uses local time, UTC or another configured zone. Do not assume a displayed clock and a file's metadata describe the same timestamp source. The distinction matters when reconstructing sequence or locating a clip.
Record the known reference and observed offset at the time of the check. If the exact historical offset is unknown, say so. A current correction does not prove that an older recording had the same error. Preserve the original record and document any interpretation separately. Editing an incident narrative to make the times appear consistent can remove uncertainty that a later reviewer needs to understand.
Reference context: Axis: device hardening guide
Check seasonal and export behavior
Where local clocks change seasonally, test how the installed system displays and searches the relevant period. A repeated local hour can create ambiguity unless the time-zone context is retained. Consult the vendor's actual behavior and supported time settings. Do not assume every recorder, player and incident platform handles the transition in the same way.
Include exports in the check. Confirm whether the player shows the camera overlay, a converted local time or another reference. Retain the original file and necessary player information through the approved evidence process. A human-readable incident timeline can explain the relationship, but it should not replace or silently alter the native recording. Use source references and note which times remain uncertain.
Correct time settings through change control
The authorized administrator should confirm the supported time source and settings for the installed system. Changing time can affect searches, logs and interpretation of recordings, so coordinate the work with the people relying on those records. Record the prior state, correction time and relevant systems. Avoid an unannounced adjustment during an active incident investigation.
After the change, check the camera, recorder, reviewing platform and exported playback as relevant to the duty. A corrected overlay alone may leave another system misaligned. Keep the results with the change reference and update instructions for anyone preparing reports. If the original discrepancy cannot be reconstructed precisely, preserve the known boundaries rather than inventing a second-by-second historical alignment.
A fictional incident with two apparently different times
A site report shows activity at 22:10 while an exported player displays 21:10. The team initially suspects a delay, but checks the sources before drawing that conclusion. One system is displaying local time and the other UTC for the relevant date. Once documented, the difference may be representational rather than an hour-long processing delay.
The timeline keeps both original values, their sources and the interpretation. If the time-zone setting cannot be confirmed for the original event, the conclusion remains qualified. The team then verifies the current camera and reporting configuration through the approved process. This approach avoids blaming transport or review latency for a difference that has not yet been understood, while preserving the record needed for independent examination.
Make the call
What explains the timestamp difference?
| Situation | Decision to make | What to ask for |
|---|---|---|
| One record is UTC and another is local time | Whether the offsets explain the difference | Date, named zone and numeric offset |
| The recorder clock is genuinely wrong | How the known offset is documented | An observed reference and separate correction note |
| A daylight-saving boundary is involved | Which repeated or skipped hour applies | Unambiguous timestamps and schedule review |
Before you move on
- Confirm the reference time source and site zone.
- Compare a staged event across systems and export.
- Document offsets and retest after time-setting changes.
A worksheet you can actually use
Start with the blank sheet. Add one row per item, assign an owner and mark anything unresolved as pending. The completed example shows the level of detail to aim for.
Keep completed security plans private. Use aliases; keep passwords, access codes, personal contacts and footage links in your approved systems.
How to fill the worksheet
- System alias
- Identify which device, recorder, player or reporting system produced the value, using a stable controlled alias.
- Reference event
- Choose an event that can be meaningfully compared and preserve the original source records where appropriate.
- Displayed time
- Retain the original displayed value instead of silently replacing it with an adjusted interpretation.
- Zone or offset
- Record confirmed zone or offset context and mark unknown historical configuration as uncertain rather than assuming today's setting.
- Observed difference
- Describe the supported relationship between values without calculating precise response latency from incompatible timestamps.
- Owner
- Assign the authorized technical check and any report update, preserving the correction history under the organization's procedure.
A worked example
Fictional event: a clip displays 02:10 while the incident record shows 01:10Z. The team checks the date and configured offset before treating the difference as a one-hour delay.
| System alias | Reference event | Displayed time | Zone or offset | Observed difference | Owner |
|---|---|---|---|---|---|
| NVR-A | Test-01 | To record | Europe/London | To verify | IT |
Questions readers bring to this task
What else should you know?
Is UTC enough for a site schedule?
UTC is useful for a common event timeline, but the site may operate by local opening hours. Keep the relationship explicit. A portfolio needs unambiguous event times and correctly maintained local schedules; one does not automatically substitute for the other.
Link to this answer ↗Should I overwrite the incident time after discovering an offset?
Preserve the original value and add a clearly documented correction or interpretation according to the organization's record process. Identify the source and reason. A silent overwrite can make the record look more precise while preventing a later reviewer from understanding what the original system showed.
Link to this answer ↗Is UTC always required?
The appropriate design depends on the systems and operational requirements. Consistent references and explicit time-zone context are essential for interpretation. Confirm the supported configuration with the responsible administrator rather than assuming one display format automatically aligns every recording and report.
Link to this answer ↗Does a one-hour difference prove network delay?
No. It may reflect time zones or seasonal settings, among other possibilities. Compare the timestamp sources and configuration before attributing the difference to delivery or review. Missing historical information should remain an explicit uncertainty.
Link to this answer ↗Notes & sources
Time synchronization settings are product specific. Preserve original evidence rather than editing timestamps to make records appear consistent.
Reviewed October 27, 2026. The examples and worksheets are planning aids, not customer results or a statement of contracted service.
- Axis: device hardening guide
Manufacturer guidance on accounts, access, network boundaries and time settings; use your equipment vendor’s instructions.
- NIST: digital video exchange standards
Video export interoperability research, not a certification of this website or a customer system.
- GOV.UK: Recovery and Acquisition of Video Evidence v3.0 (2022)
Native retrieval, playback and source context. A formal forensic procedure requires appropriate expertise.