Surveillance Pet Peeve: Daylight Savings Time

With DST just starting here in the Eastern time zone, I'm reminded of one of my least favorite issues in IP cameras and recorders: forcing me to manually set up DST. With time being such a critical issue, you'd think it would be addressed better.

For example, setting up some Panasonic cameras today, I have to manually select my time zone, then choose whether I want to manually control DST or set it to auto. If set to auto, I have to pick when it starts/stops on my own. I'd be willing to bet a lot of users don't know when DST actually starts and stops, and this process is prone to user error. Why not simply load settings based on the time zone I selected and take the guess work out? This is unfortunately

Even worse is this, from a D-Link switch...asking me to specify the exact dates it starts and stops. In other words, requiring the user to update these dates every year. I find this one the most baffling, and D-Link is by no means the only one doing this, just the most recent example I found.

If PCs and iPhones and all sorts of other devices can automatically determine my time zone and adjust for DST, why can't IP cameras in 2016?

If PCs and iPhones and all sorts of other devices can automatically determine my time zone and adjust for DST, why can't IP cameras in 2016?

Because they are directly connected to the Internet, and security cameras are not typically.

What regions worldwide use Daylight Savings Time and when is constantly changing, so there is no way for a isolated camera to know what the current settings should be.

Maybe the system itself isn't connected, but most often users configuring it are. So download an update to DST settings during config.

I don't think the changes to DST are so great that some effort is wasted. Sure, it may end up out of date, but it's better than the literal nothing that's done now in a lot of cases.

So download an update to DST settings during config.

That makes sense. Auto-fill based on the current data.

I don't think the changes to DST are so great that some effort is wasted.

Though, in the U.S. at least the dates change every year. Maybe more of an argument to auto-fill multiple years?

In 2007 in the U.S. they moved a whole month! Worldwide, it's even more volatile with countries getting in and out after legislation.

If you are syncing to a NVR/VMS with outside access you would think that would keep the time right, though I believe there are some VMSes that just update the UTC and leave the TZ up to the camera.

I have a Panasonic phone system with the same setup as your camera, it is still wrong every spring and fall for a month. I would change it, but it's a pain in the ass. I'm hoping that the U.S. justs goes back to the 2006 times. :)

Though, in the U.S. at least the dates change every year. Maybe more of an argument to auto-fill multiple years?

The actual calendar date changes, but it still happens at the same interval: move ahead the second Sunday of March, move back the first Sunday of November. Make your system do it based on that, and you don't need to pre-load a bunch of future dates.

I have a $25 Wal-mart clock sitting on my night stand that figures out DST just fine and it is NOT connected to the internet. Just sayin'.

One like this, $24 at Walmart?


Maybe Im missing something but why not implement a TIMENET POE VTN-TN from VERACITY and just configure your cameras to always get the most geo accurate timings?


That's only part of the battle. Time sources, including the Timenet, generally only supply GMT/UTC. It's up to the individual time client to apply the proper time zone/DST.

So that's a start, yes, but you can still be hours off if you don't set things right.

Also, other countries around the world do/don't use DST, and have changed the dates as well.

I will say it is better than Panasonic older models, where it was in/out. No auto option. You had to manually change it twice a year.

You could script the change (CGI comamnds) so you don't have to do it to each camera. I can help if you need the script to set the correct entries for DST.

I think it has to do with 1) the table size for DST and 2) the changes to it.

When I was at Panasonic, changing the DST month was a big deal - requiring firmware updates for all products, some requiring complex procedures to update the table.

Now, their NVRs do have the full table and will handle this better. Older NVRs had a 10 year calendar or so, so you just had to do it every once in a while...

And YES, DST was a big pet peeve of mine. Also trying to explain that NTP is not the same as DST. You have to have the time zone & DST option correct for NTP to be correct. People would call in saying my time is off by an hour, saying they are using NTP. But without setting DST setting, the camera wouldn't know to offset it...

John Oliver has a good summary of Daylight Savings Time

I have just encountered an interesting problem with video files related to DST. We had a request to download video from 1 to 3 am on the night of the change. The police officer could not get it that one hour doesn't exist but finally did. Here is my question, when we go the other way VMS will be recording the same hour for 2 hours how will it show in the recording? This could have grave consequences if this video ever goes to court. I never thought of this until this request last night.

I never thought of this until this request last night.

You now join the distinguished company of those who have also contemplated the mind bending consequences of temporal shifting:

Surveillance Systems & The Daylight Savings Disaster?

VMS Automatically Adjusts For Daylight Savings?

Chillingly, it has been theorized that a group of highly technical thieves could exploit just such a weakness, most likely in the 'Fall behind' change, due to the possibility of the inadvertent rewriting of the 1-2 AM time slot.

And although these hypothetical 'time bandits' have never been captured in the act, that's exactly what we would expect now isn't it? ;)

Just my two cents:

I managed a Cisco Stream Manager (Sypixx) System at a casino for many years and every fall was a disaster, (I actually had an issue with Spring DST for several years until I re-loaded the Linux and Recorder image on all the DVRs again.) Cisco never had a fix for this. (Actually, their fix was to End of Life Cisco Stream Manager.)

Video would playback in 5 minute clips, then switch to the other 2am and do this loop. It was completely worthless. Every fall since I had managed the system until I left company, I had to go in at 2am on Sunday morning and wait for the system to roll back to 2am and wait for any one of the operators to have a review. I would then have to figure out manually which was the original 2am; Telnet into each DVR(could have been multiple DVRs), from the command line move one of the 5 minute segments to a "temp" folder in the Linux directory so the playback sequence was't disturbed by the looping, then I would give the operator the OK to review the video and then they would export without issue. Then I would move the original file back. After 30 days the video would write over the DST video and things were back to normal until the next year. Thankfully the casino replaced their system several years ago!

Bumping and pinning this for the next few days given today's daylight savings time change in the US.

We have Zero problems with Genetec, we make sure the cameras DON'T put a overwrite box of any time or date info into the stream, and the VMS takes care of it all. As an example I am at work right now looking at an example of the switch over, it goes from 0159 hours to 0300 hours, there is no info for 0200 to 0259, in 6 months if I remember you have 0159 to 0200 twice in the archive. We let the VMS control all time and date stamping on video as well as saved photos from the video. The VMS and all cameras are configured to pull time from our local NTP server. We had an issue a couple of years ago, Genetec failed to update as we changed the IP for the NTP server and all we did for evidence is make a reference to the report it was attached to. It will hold up as evidence, if it is noted in the report at the time it is written. I can imagine it could be a problem with smaller system that relay on a NVR or DVR with old firmware. Also it is not so easy for a universal system, look at the uses of DST across the U.S.A

From Wikipedia:

Daylight saving time in the United States is the practice of setting the clock forward by one hour during the warmer part of the year, so that evenings have more daylight and mornings have less. Most areas of the United States observe daylight saving time (DST), the exceptions being Arizona (except for the Navajo, who do observe daylight saving time on tribal lands),[1] Hawaii,[2] and the overseas territories of American Samoa, Guam, the Northern Mariana Islands, Puerto Rico, and the United States Virgin Islands. In general, daylight time is not observed in lower-latitude regions, as summer days are not much longer than winter ones as in higher latitudes, so the advantage of the change is smaller.

Daylight saving time starts on the second Sunday in March and ends on the first Sunday in November, with the time changes taking place at 2:00 a.m. local time. With a mnemonic word play referring to seasons, clocks "spring forward and fall back"—that is, in springtime the clocks are moved forward from 2:00 a.m. to 3:00 a.m., and in fall they are moved back from 2:00 a.m. to 1:00 a.m. Daylight saving time lasts for a total of 34 weeks (238 days) every year, about 65% of the entire year (including leap years).

The following table lists recent past and near future starting and ending dates of daylight saving time in the United States:

Year Start End
2014 March 9 November 2
2015 March 8 November 1
2016 March 13 November 6
2017 March 12 November 5
2018 March 11 November 4
2019 March 10 November 3
2020 March 8 November 1

Unless TZ data is large enough to be a concern when building firmware for small IoT devices, there is no excuse for requiring manual entry of DST settings. At least I can't think of any. My Raspberry Pi doesn't require this, and it doesn't need an internet connection to figure it out.

That said, for most places the DST change is typically predictable (second Sunday of March for example), so it should be a set it and forget it thing. Except, on occasion the DST schedule does get changed. Manual override then becomes necessary to accommodate for this between firmware updates. And of course there's the risk of human error.

More likely in my experience, people don't touch the time settings at all. This is usually fine when using a VMS as the server side time is used instead. But on occasion it can be beneficial for the camera to have an accurate system time. When it becomes necessary to correlate server and camera logs for example. I'm also partial to including timestamp overlay on cameras as it provides one additional point of reference.

On the VMS side, our XProtect Corporate and XProtect Expert products seamlessly include both 2am hours in the timeline in playback for the "fall back" DST change.

During all the election debate I made my voting position clear: if one candidate would promise we would Spring Forward in 2017 and never Fall Back again they would have my vote, campaign donations, and volunteer time. Hillary, Trump, Johnson, or Beelzebub, I'd be in 100% on this one issue. Camera concerns aside, I have kids and my wife works at a school. Hurricanes scare teachers less than time changes.