Quick answer: Record the actual error and any footage-preservation need before changing time. Verify the supported synchronization path, site/display zone and current local daylight-saving rule for each device/client; NTP synchronization and time-zone display are separate settings. Test recordings, searches and exports after an approved correction and document the old/new time basis. A clock error can complicate correlation, but it does not automatically prove missing footage or decide legal admissibility.
On this page
Why does an incorrect clock make recordings harder to review?
A wrong time or inconsistent display zone can make the operator search the wrong interval or misalign clips and external records. Document the actual time basis, offset, reference and uncertainty instead of assuming the camera did not record. Preserve relevant sources/logs before changes and involve the authorized case/evidence reviewer where needed. An accurate clock or an installer log alone does not authenticate footage or guarantee admissibility; the applicable proceeding and evidence process determine that question.
| Symptom | Possible checks | Do not assume |
|---|---|---|
| Search appears to miss an event | Actual recorder/camera/client time basis, zone, schedule and available recordings | A clock mismatch means no recording exists |
| Two displayed times differ | Overlay origin, display conversion, actual sync/zone and export behavior | Different displays prove different underlying recorded instants |
| A device/client fails authentication | Actual auth method, error/logs, clock freshness and other network/credential factors | Every ONVIF login has one universal time tolerance |
| Repeated or skipped local hour | Actual supported DST/history/display/indexing and continuous recording | A skipped wall-clock label proves a one-hour footage gap |
| Recipient questions a timestamp | Source/offset/reference and documented actions/limitations | A wrong clock automatically invalidates every clip |
How do you set NTP and the time zone on a CASE NVR?
Use current exact-model/firmware instructions and agree the site’s time architecture before changing an existing system. Supported clock source, server/client behavior, zone/DST and recording effects can differ. Do not assume all fields or menus exist, every channel inherits the recorder’s time, or one setting should be pushed to every device without a preservation and test plan. Check the NVR firmware download resources for approved revision instructions; do not assume every release contains updated local time rules.
- Record current device/client time, zone/DST, synchronization status and reference/offset; preserve relevant footage/logs and required holds before corrections.
- Identify the actual site and current legal/local time rules. A familiar firmware city label may contain outdated DST data; verify the intended behavior on both sides of the next transition.
- Use approved reachable and trustworthy synchronization sources appropriate to the network, including redundancy where supported. The NTP architecture need not be one single server for every device; do not enable arbitrary public access or repurpose a server without IT approval.
- Configure only supported approved settings. NTP commonly uses UDP123, but actual destinations, direction and firewall rules follow the selected design; time synchronization does not itself set the local zone.
- Verify actual recordings, searches, overlays, client display and exports. Test reboot/loss-of-sync recovery only in an approved safe procedure, not by interrupting required live evidence recording.
Keep approved time sources, addressing/reachability, device/client versions, zone/DST rules, current status and actual tests in the controlled handover record. The time, logs and certificates setup guide covers the related checks. Document how time changes and unresolved drift are handled; a checkbox is not proof of continuing synchronization.
How do you sync the cameras from the NVR?
Identify which device/client generates each overlay, metadata timestamp and display conversion. Not every camera burns in its own time, and some systems intentionally store UTC while showing local time. Agree a consistent, traceable time basis and test it throughout recording and export rather than forcing every display to one zone without understanding the architecture.
Cameras on the NVR’s PoE ports
Confirm whether the exact recorder supports time push, an NTP-server role or another synchronization method and whether the actual camera accepts it. CS-N220 P16H-AI’s printed gigabit/PoE interface rows do not establish subnet isolation, routing or time service. Do not bypass camera isolation to change a setting; verify the approved reachable source and actual device behavior through supported controls.
Cameras on the customer LAN
For LAN cameras and non-PoE recorders such as CS-N880 H-AI, verify each actual supported time mechanism and permitted path. An NTP-client capability or source cannot be assumed solely from port type or product family. Where a common reference architecture is used, check successful sync and intended display conversion; equal server text or zone labels alone do not prove the recorded instants match.
ONVIF and third-party devices
Some ONVIF/security authentication methods use freshness timestamps and can be affected by clock skew; inspect the actual error and supported mechanism rather than assuming one tolerance or checking time instead of every other cause. ONVIF camera not connecting to NVR covers the broader sequence. For a required ONVIF conformance claim, verify the full model and firmware in the official ONVIF database. Then test the required streams, recording, playback and events with the actual client/version. A profile list or brand name is not a complete integration statement. Compare actual synchronized time, overlay/display origins and uncertainty; a few seconds of difference alone does not prove another server was selected.
Where do DST and multi-site jobs hide mismatches?
Time-zone and seasonal rules vary by locality and can change. Verify current official guidance for the installation location and the firmware/client’s actual rule behavior. As checked on 2026-10-29, B.C.’s new Pacific time stays UTC-7 after the March8,2026 transition and does not fall back on November1; eastern mountain-time communities are exceptions. Do not copy the old rule that all of British Columbia changes with the US Pacific coast. Check other provinces/states independently, including any recent changes.
| What to verify | Record for this actual site | Test |
|---|---|---|
| Jurisdiction and current rule | Official source, locality, verification date and any exception | Expected offset/behavior on relevant dates, not just a region name |
| Firmware/client zone support | Exact versions, selected zone and actual seasonal rule data | Approved transition/reboot tests without risking live footage |
| UTC versus local display | Source timestamps, overlays, recorder search and client conversion | A known recorded instant correlates across views and export |
| B.C. Pacific 2026 change | Applicable UTC-7 area or documented eastern exception | Correct November1 behavior; no blanket province-wide preset |
| Multi-site operation | Each site’s time basis and central operator conversion | Cross-site search/export with explicit zone/offset and limitations |
Where a seasonal fall-back applies, a local wall-clock label can repeat; a spring-forward skips labels, not necessarily actual recording time. Verify how the exact system stores, indexes, displays and exports both occurrences/continuous footage, including gaps if any, through an approved non-production-recording test on authorized equipment. Do not claim a repeated label necessarily overwrites footage or a skipped label necessarily means no recordings. Multi-site systems can use an approved UTC/local architecture; retain unambiguous zone/offset and conversions.
How do you document time when you export evidence?
Record actual observations for each relevant acquisition: source and client identity, date/zone/DST, reference/offset and its timing, supported export options and any correction history. An example is not a measured result or certification. The responsible evidence/case process determines what additional records are required.
| Field | Actual entry to collect |
|---|---|
| Source and client | Full recorder/camera mapping, versions and relevant display/export path |
| Reference and observation | Identified reliable reference, observation date/time and how compared |
| Offset/time basis | Measured difference, zone/UTC offset, DST and uncertainty or missing data |
| Sync state | Configured approved sources and actual last-sync/status evidence where supported |
| Requested/exported interval | Source and recipient time basis, actual channels and boundaries |
| Actions and results | Authorized settings/correction, old/new observations, recording/search/export tests and pending issues |
- Record source/reference and offset before an approved change, preserving relevant footage, logs and holds.
- Use the authorized supported acquisition process and document actual formats, player/metadata and verification; a player label is not an automatic integrity certificate.
- Transfer records securely only to authorized recipients and retain the case/custody information; do not put credentials or unnecessary footage in a general email.
- Make a clock/zone correction only under the approved preservation/operating plan. Record old/new values, reason, authorization, effect and verified future behavior; export completion alone does not automatically authorize the change.
The export workflow is in finding, clipping and exporting evidence from a CASE NVR.
What to tell your customer
We will document the system’s current time basis, verify the approved synchronization and current local time rules, then make and test any authorized correction. Before an evidence export we will record the reference and observed offset. The handover will explain how timestamps are displayed and correlated, including any remaining limitations.
FAQ
Why is my NVR time wrong even though NTP is enabled?
Possible causes include unreachable/untrusted source, wrong zone/DST or stale firmware rules, rejected responses, a disabled/failed client or other device/configuration faults. Check actual sync status/logs and observed time against the approved reference. A server address or NTP-enabled checkbox is not a pass, and a correct NTP clock can still be displayed in the wrong local zone.
Should the NVR be set to local time or UTC?
Use the supported approved site/multi-site architecture. Some systems store UTC and display local time; others use different documented behavior. Confirm actual local rules and make source, overlays, searches and export conversion unambiguous. Do not impose one universal local-only rule or force every camera/client to the same label without testing the actual result.
How do I keep the cameras’ time in sync with the NVR?
Verify supported synchronization and a coherent reference architecture for each actual device and path; redundant approved sources can be appropriate. Do not assume PoE-port cameras take time from the NVR or LAN cameras have a specific client. Check actual status and recorded instants/overlays/conversion, with exact versions and source/zone settings documented. Use the camera network planning guide for the permitted network paths.
What happens to recordings when the clocks fall back in November?
Only where that locality currently falls back, wall-clock labels can repeat. Verify the actual system’s indexing, storage, playback and export with the zone/offset identified; do not assume the second hour overwrites the first. Spring-forward labels can skip while actual recording remains continuous. B.C.’s new Pacific zone does not fall back in November2026; verify the actual site and any exception.
Can a wrong clock stop an ONVIF camera from connecting?
It can affect authentication mechanisms that rely on timestamp freshness, but behavior and tolerance depend on the actual device/client method. Check exact errors, time basis and synchronization alongside other network/credential/integration causes. For a required ONVIF conformance claim, verify the full model and firmware in the official ONVIF database. Then test the required streams, recording, playback and events with the actual client/version. A profile list or brand name is not a complete integration statement. Do not infer universal profile support or prescribe a credential reset from a clock symptom alone.
References
- Anabon: exact model/revision documents
- Anabon Technical Support
- IETF RFC8633: NTP operational best practices
- B.C. government: 2026 Pacific time change and eastern exceptions
- NIST: current US daylight-saving rules and exceptions
- ONVIF conformant products and exact firmware
