A security camera can capture the right event and still produce a confusing record if its clock is wrong. A phone notification may say 9:14 p.m., the video overlay may say 8:14 p.m., the exported filename may use UTC, and another camera may place the same person 47 seconds later. That makes an ordinary incident harder to reconstruct.
This checklist is for homeowners who want consistent event times across cameras, alarms, smart locks, routers, hubs, phones, and exported files. It does not promise that footage will meet a court or insurer’s requirements. It gives you a repeatable way to find clock drift, daylight-saving errors, stale timestamps, and export mismatches before an incident.
Quick answer: what should match?
At minimum, every device should agree closely enough that one event can be placed in the correct sequence. Record the camera overlay, app timeline, push notification, alarm event, lock event, router or recorder time, exported filename, file metadata, and the trusted reference clock used for the test. Do not silently “fix” a discrepancy in your notes. Preserve the original value and record the correction separately.
| Clock or timestamp | Where it appears | What to verify |
|---|---|---|
| Camera clock | On-screen overlay or camera settings | Time zone, daylight-saving setting, synchronization source, and drift after 24 hours |
| App event time | Event list, notification, playback page | Whether it follows the phone, account, property, cloud, hub, or camera time zone |
| Recorder or hub clock | NVR, DVR, HomeBase, controller, or alarm history | Time zone, network time source, restart behavior, and per-camera consistency |
| Phone clock | Push notification and screenshots | Automatic time and time-zone settings, travel state, and screen-capture time |
| Exported-file time | Filename, visible overlay, container metadata, file creation date | Which value is authoritative and whether copying changes filesystem dates |
| External reference | Trusted time service or automatically synchronized phone | The reference, observed time, time zone, and test operator |
Build a timestamp inventory before testing
List every camera, doorbell, alarm hub, lock, recorder, storage target, router, access point, smart-home controller, phone, tablet, and computer that can create or display an event record. For each device, write down its exact model, firmware, account owner, time zone, daylight-saving rule, network connection, time source if exposed, overlay setting, storage path, and export method.
Keep this inventory with a home-security change log. Clock behavior can change after firmware updates, router replacement, account migration, factory reset, or a move to a new time zone.
Choose one reference and record the offset
- Use a phone or computer with automatic date, time, and time-zone settings enabled. Record the reference device and its displayed time zone.
- Place the reference clock in view of each camera where practical. Trigger a visible action, such as switching a light on, at a noted reference time.
- Record the first frame showing the action, the overlay time, the app event time, and the push-notification time.
- Calculate each offset from the reference. Keep the sign: “camera is 18 seconds slow” is more useful than “18-second difference.”
- Repeat after 24 hours and again after seven days. A stable offset and a growing offset are different faults.
A small, stable offset may be acceptable for a household alert system. A growing offset indicates drift. A one-hour offset usually points to daylight-saving or time-zone configuration. A whole-number hour difference in an export can also mean one view is local time and another is UTC.
Run one event across every system
Use a lawful, ordinary test event that appears in multiple records. For example, open a test door, enter a lock code, walk through two camera views, and acknowledge the alarm notification. Do not trigger emergency dispatch. Save the physical event time, contact-sensor event, lock event, each camera’s first useful frame, notification receipt, recorder entry, and export.
| Sequence item | Record | Pass condition |
|---|---|---|
| Physical start | Reference-clock time and a visible or audible cue | The starting point is unambiguous |
| Direct sensor or lock | Device event time, app time, and notification receipt | The event order matches what happened |
| Camera 1 | First useful frame, overlay, app timeline, and export | The offset is measured and documented |
| Camera 2 | The same four values | Cross-camera order remains correct |
| Acknowledgment | Phone time, user, action, and app history | The response follows the recorded event |
Inspect the exported file, not only the app
Export one representative event using the normal household process. Keep the original download untouched. Record the provider, account, camera, event ID if available, download time, filename, displayed clip time, visible overlay, file duration, file size, and cryptographic hash if the event matters. Open it on a second device.
File creation and modification dates can change when a clip is copied, uploaded, unzipped, or sent through a messaging app. Treat those filesystem dates as handling records, not automatic proof of when the camera captured the event. The camera evidence export checklist covers preservation and sharing in more detail.
Test reboots, outages, and reconnection
Clock problems often appear after a device loses power or network access. Run only safe tests that will not interrupt emergency monitoring or another occupant’s access.
| Test | Check before, during, and after | Fail condition |
|---|---|---|
| Camera reboot | Overlay, event time, first recording, gap, synchronization delay | The clock resets, jumps, or records misleading events |
| Router or internet loss | Local recording, queued alerts, recorder clock, cloud timeline, restoration order | Events reorder or the gap is hidden |
| Recorder restart | Per-camera time, playback timeline, oldest footage, export metadata | One channel returns with a different offset |
| Property power loss | Backup runtime, shutdown time, restart time, gaps, time source | The device returns with a default date or unmarked gap |
| Phone travels | App display before and after time-zone change | Old events appear to move or lose their property time zone |
Handle daylight saving and time-zone changes
Test the week before and after a daylight-saving transition when your region observes one. Record whether the camera, hub, app, and export show local time, UTC, or both. If a property has viewers in different zones, ask each person to capture the same event screen. The account owner should document which display is expected rather than assuming every viewer sees the same time.
After a move, account transfer, or long trip, verify the property time zone separately from the phone time zone. Do not change a camera clock merely to make an old clip look correct. Preserve the original record and note the known offset.
Set an acceptance threshold
There is no universal household threshold. Choose one based on the job. A live-view convenience camera may tolerate more variation than a multi-camera evidence path. A practical starting rule is that the event order must remain correct, offsets must be documented, and drift must not grow between checks. If exact timing matters for insurance, employment, tenancy, or legal use, ask the relevant professional what record and tolerance they require.
Fix the cause and keep a before-and-after record
- Save screenshots and one original export before changing settings.
- Confirm the property time zone, automatic daylight-saving setting, network connectivity, and available firmware.
- Enable the vendor-supported automatic time source where available. Avoid undocumented workarounds.
- Restart only if the vendor’s process calls for it, then repeat the reference-clock and multi-device test.
- Record the old value, new value, operator, date, reason, result, and rollback path in the change log.
If the device continues drifting, contact the vendor with the model, firmware, measured offsets, time zone, network state, restart results, and sample event IDs. Replace or isolate a device whose timestamps cannot support the required job.
40-minute timestamp acceptance test
- Minutes 0–7: inventory cameras, alarm, locks, recorder, storage, apps, viewers, time zones, daylight-saving rules, firmware, and the reference clock.
- Minutes 7–15: place the reference clock in view and capture one visible cue on every camera.
- Minutes 15–23: run one door, lock, camera, and notification sequence; record every displayed time and offset.
- Minutes 23–30: export one clip, preserve the original, open it on a second device, and compare filename, overlay, app time, and file metadata.
- Minutes 30–36: run one approved camera or network restart test and record gaps, synchronization delay, and restored offsets.
- Minutes 36–40: sign the pass threshold, discrepancies, fixes, owner, next 24-hour check, seven-day check, and escalation route.
Related checklists
- HomeKit security incident documentation
- No-subscription home-security evidence checklist
- Home-security return-window acceptance test
Frequently asked questions
Why is my exported clip time different from the app?
The app may display the viewer’s local time while the filename or metadata uses the property time zone or UTC. Record every value and the known offset rather than renaming the original file.
How often should I check camera clock drift?
Check after installation, 24 hours later, seven days later, after firmware or network changes, after a power outage, and around daylight-saving changes. Repeat quarterly for an evidence-critical setup.
Does the video overlay prove the capture time?
No single field proves the whole timeline. Compare the overlay with the app event, recorder, notification, trusted reference, and original export, then document discrepancies.
Should I correct the clock before saving an important clip?
Preserve the original clip and screenshots first. Record the observed offset, then make a documented correction and run a new test. Do not alter the original evidence to hide the discrepancy.
