Skip to content

Local NTP server - Daylight Savings Time

edited January 2020 in SecuritySpy
What is everyone using for ntp servers on the local network to handle daylight savings time correctly?

The reason I ask is like most cameras, all of my cameras have a setting to use an NTP server of your choice. My problem is twice a year when daylight saving time starts or ends I have to manually logon to each camera (24+) and click the daylight savings time box to get the time displayed correctly. Then again a few months later to switch it back. Any of the cameras that have built in rules are also of no help since the rules change occasionally.

I used to have a mac mini server that could function as an NTP server, but apple orphaned the server software and it no longer runs on current macOS versions. On top of it being orphaned it simply reported the UTC time for my time zone and did not correctly report daylight savings times to the ntp clients. (DST is handled by the OS and not passed on to clients) In that case I could just simply change the time zone of that one single mac mini server twice a year and all the cameras would update.

A pain for other obvious reasons, but twice a year it was at least workable.

Any software out there than can handle this task?

PS. I've googled the cr@p out of this and have been unable to get any of the so called "fixes" to work.
Thanks in advance, for the discussion/solution.

Comments

  • Usually the NTP server acts as a source for Universal Time Coordinated (UTC). You don't move UTC back and forth to implement DST/SD shifts. UTC is UTC.

    Instead, you typically have options in the client device (camera) to set time offset (time from UTC) to match your time zone. DST/SD is usually handled as an on/off option in the camera's time settings. Modern camera firmwares also implement a means of setting when DST starts and stops based on day of week, week of month, and changeover time. Lacking such an option to automatically switch, you manually turn DST on/off manually.

  • @guykuo....thanks for your reply, but I think you completely missed my question.

    I didn't say you move UTC around, I said, you changed the time zone. Like in UTC -8 or UTC -7 etc.

    Yes, UTC is UTC, it's the periodic manipulation of UTC that is the issue. Within the time zone there is a further manipulation of UTC depending on the zone/state/area you are in and whether or not they use DST or not.

    I must have also been too subtle with my reason of why the "modern firmware" fix doesn't work. -->The start/stop settings DO change over time and it doesn't help when the government changes the rules periodically.

    I was vaguely trying to say..... it's a PAIN IN THE @$$ to change every camera twice a year (manually).

    I don't want to turn DST off/on manually, that's the point of this post. There has to be an easier way. An automatic way for camera owners in a DST areas, that doesn't require me logging into 24+ cameras twice a year.
  • edited January 2020
    Sorry, I did not realize you are in a part of the globe where DST shifts around so frequently. Here, in most of the US, we are fortunate to have had no changes in the DST law since 2005. That allowed setting the camera to auto change on the 2nd March Sunday and 1st Sunday November to be a workable/essentially permanent solution for quite some time.

    I can see that it would be a pain in a part of the world whose government frequently adjusts the law. Maybe you could do what you did on the Mac mini with a Raspberry Pi and GPS receiver. You would have to offset its NTP service, but I'm sure you will find a way.
  • The more I look at this, the more I think creating an undisciplined, incorrect time, NTP server is a really bad approach to a client side issue. Cryptography and other systems relying on UTC could become problematic. DST really should be dealt with at the client device, not the NTP server. Sorry your government so frequently changes your DST law.
  • Agreed that messing with the time has other consequences.

    I'm not thinking I would point anything on my network to the modified ntp server except the cameras.

    Of course I could just invest in new cameras that have DST settings that work properly. I guess that's my real issue, I'm looking for a cheap(free) simple solution. Seems like it should be easy piece of software to run in the background on one of my machines. Maybe a RP or perhaps something on a windows machine.
  • edited January 2020
    I vaguely remembered it, but look at this thread about adding an openNTP server on a MacOS machine.

    https://www.bensoftware.com/forum/discussion/2726/adding-ntp-server-to-securityspy#Item_1

    Maybe that could get you back to same state you were before Apple stripped out the server.
  • Yes, the DST adjustment has to be done in the cameras. Most cameras have options to do this automatically (e.g. +1 at 01:00 on the last Sunday in March) but, as you say, some cameras have inadequate controls for this that don't always match up properly to the rules in every area. Unfortunately the only option (without replacing cameras) is to use these in-camera controls to most closely match the DST rules in your region - at worst you'll have 1 hour timestamp errors for a couple of weeks in the year.

    The other option is to use SecuritySpy's own timestamps, which will always be correct if your Mac has access to a time server, but this does require recompressing the video feeds, which uses significant CPU and degrades quality, so I wouldn't recommend it.
  • @guykuo - Thanks for the link to the thread detailing how to get and NTP server running on a mac. This is a step in the direction I was looking for. I play with this for a bit.....
Sign In or Register to comment.