CCTV
CCTV Time Is Wrong: Align Camera Clocks, NVR Playback and Exports
When a camera overlay, recorder timeline and exported clip disagree, finding an event becomes guesswork. Separate clock accuracy from display time zones, identify who controls synchronisation and test one recognisable event.
When CCTV time is wrong, compare the camera overlay, the recorder timeline and the viewing device before changing the clock. NTP keeps a device clock synchronised; the time zone and daylight-saving settings determine how local time is displayed. Correct the device that owns the setting, then verify a new recorded event.
A delivery is logged at 14:00, but the camera overlay says 13:00. The recorder timeline appears to show something else, and the exported file has a different creation time again. It is tempting to add an hour everywhere. That can produce another mismatch while hiding the original cause.
The useful question is not simply “Which clock is wrong?” It is which layer is presenting each time, and whether the difference stays fixed or grows.
Separate the Times You Are Comparing
| Time You See | What to Establish | What It Does Not Prove |
|---|---|---|
| Camera date/time overlay | Which device or setting creates the text inside the picture | That the viewer timeline uses the same display zone. |
| NVR or application timeline | The recorder’s clock and the application’s display behaviour | That a burned-in overlay has been changed. |
| Viewer computer or phone | Its current zone, clock and application preferences | That every remote site should use the viewer’s local zone. |
| Export filename or file creation date | How that exporter names and creates output files | The original capture time, without checking the clip and its metadata. |
A timestamp drawn into encoded video pixels is part of that recorded picture. Correcting today’s settings does not repaint it in an old original clip. Keep original exports intact and note the observed offset separately.
Use the Offset to Narrow the Cause
| Pattern | Likely Area to Investigate | Next Check |
|---|---|---|
| Exactly one hour out | Time zone or daylight-saving configuration | Check the site’s actual zone and whether DST should apply. |
| Several whole hours out | UTC versus local display, or the wrong zone | Compare the same event across recorder and viewer settings. |
| A small difference that grows | Clock drift or unsuccessful synchronisation | Check time-server reachability and sync status. |
| It changes again after reconnecting | Another device may be managing the clock | Establish whether the recorder overwrites camera time. |
| Live picture looks a few seconds behind | Stream and display delay may be involved | Use one recognisable recorded event, not only a live-view glance. |
These patterns guide the next test; they do not identify a fault with certainty. Record the date, zone and actual difference. “One hour late” is incomplete if the clocks were checked on different days or across a seasonal clock change.
Put Synchronisation in the Right Place
VIGI Camera and Recorder Systems
VIGI documentation provides automatic time synchronisation and time-zone settings. It also explains that an NVR-connected camera can receive its NTP and DST settings from the recorder. Check the NVR first if a camera-only adjustment keeps reverting. Menu wording varies with model and firmware.
Foscam Installations
Foscam’s documented device-time controls separate time zone, NTP synchronisation and DST. Verify the settings available in the actual camera or recording software, and establish whether a connected recorder is also managing time. Do not assume every older VMS menu is identical to the current app.
UniFi Protect Systems
Check the console, recording application and viewing device as a system. Establish the intended site zone and verify time-service access rather than copying a VIGI camera menu into Protect. Ubiquiti’s network requirements include outbound NTP on UDP 123; restrictive network rules can therefore be part of the investigation.
Use the existing approved network policy or ask the network administrator to verify the required path. An inbound internet port-forward is not required merely to let a device obtain time. On a deliberately isolated system, use a reachable approved local time source where the platform supports it.
Keep UTC, Local Time and Daylight Saving Separate
NTP addresses clock synchronisation. It does not choose the correct local time zone for a site. Two correctly synchronised systems can display different local hours because their configured offsets differ.
One Instant, Different Local Times
All three clocks below can be correct at the same moment.
UTC
06:00The reference instant
UTC+8
14:00Local display adds 8 hours
UTC+7
13:00Local display adds 7 hours
In the diagram, 06:00 UTC, 14:00 at UTC+8 and 13:00 at UTC+7 describe the same instant. Changing the clock itself just to make two differently configured displays show the same digits can create an error.
Choose the correct site zone, then check whether daylight saving is applicable. A fixed one-hour mismatch often deserves that check before any manual clock adjustment. For multisite viewing, document whether the application shows site time, viewer time or another selected zone.
Make One Controlled Correction and Record a New Event
- Record the current camera overlay, recorder time, viewer zone and observed offset before changing settings.
- Identify the device that controls synchronisation and correct its source, zone or seasonal setting as appropriate.
- Check that synchronisation actually succeeds. Saving a server address does not prove the device can reach it.
- Perform a recognisable event, such as walking through the entrance, and note the time from an agreed reference.
- Find the event in recorded playback, export a short clip and compare the displayed times with the reference.
- Recheck after the next normal synchronisation interval or later in the day to see whether the difference returns.
A planned clock correction can affect how a recording period is presented. Retain a note of when and why the setting changed. Do not delete old recordings, erase disks or alter original clips to make a timeline look tidier.
If the correct event is found but its exported picture is poor, the CCTV playback and export guide addresses that separate problem.
Check the Recording Platform, Not Just the Camera Label
Choose a camera and recorder that fit the same intended workflow, then hand over the time settings as part of the system record. Include the site zone, who manages synchronisation, the time source and a saved test result. Do not assume a mixed-brand installation shares every configuration control.
Check the UniFi console, Protect application and viewer together when verifying the site’s recording time.
Confirm whether the recorder manages the connected cameras’ time and seasonal settings.
Check device-time settings and how the intended Foscam recording workflow handles synchronisation.
For mixed systems, the camera and NVR compatibility guide explains why a working video stream is not proof that audio, events, AI or configuration features are equally integrated.
The finish line is a correctly found event. A saved time setting is only the start. Verify the same new event in camera view, recorded playback and export, and retain the settings record so the result can be checked again.
Frequently Asked Questions
Why is my CCTV exactly one hour wrong?
Check time zone and daylight-saving settings first. A fixed one-hour offset differs from a clock that gradually drifts, although the observed pattern alone does not prove the cause.
Will NTP automatically choose the right local time zone?
No. NTP synchronises a device clock; local time-zone and seasonal settings are separate. A synchronised clock can still be displayed with an unsuitable local offset.
Why does the camera time revert after I correct it?
A connected recorder may manage the camera’s time. Establish which device owns synchronisation and apply the correction there, following the actual platform’s instructions.
Why is an export’s creation date different from the event?
The export file may have been created when you downloaded it. Compare the recorded event, displayed overlay and supported metadata rather than using file creation time alone.
Can an offline CCTV network keep correct time?
A supported system can use a reachable approved local time source, or its documented manual method. Without successful synchronisation, monitor for drift and record checks rather than assuming a manually set clock stays accurate indefinitely.
Will correcting the clock fix timestamps inside old video?
A correction does not rewrite an overlay burned into an original recording. Preserve the original clip, record the observed difference and verify a newly recorded event after the settings change.
