Question:

CentOS configure ntpd to serve DST/localtime

Aaron: 02 February 2022

I know that ntp uses UTC and the clients have to manage any DST and timezone differences on their own.

The problem I have is that several noname ip cameras have a non-working DST implementation, and randomly add/subtract hours, resulting in almost always incorrect time. All of the cams allow to sync with ntp servers, though. So I thought one way around the problem would be to serve the local time including DST (if applicable) as "UTC" to the cameras, and turn off any timezone/DST settings. Is this possible (without messing up the linux system)?

The CentOS system is running in a VM and is synching its time from another ntp host on the network. No other systems sync with this system, so the ntpd time would be only for the ip cameras. The CentOS system itself has to continue working with the correct time.

In case this is a really bad idea, I'm also open to other suggestions ;)

Answer:
Gianna: 02 February 2022

In my opinion it's a really bad idea. NTP servers that lie almost always end up causing problem - just look on ServerFault - not least for themselves. The requirement that the CentOS system the faulty ntpd is running on still needs to know the right time should clarify why this won't end well (you could have a small, sacrificial VM that knew only the wrong time, and advertised it - but that's still not a good idea).

If your cameras can't do DST, then run them in UTC. Turn off any timezone and DST settings on the cameras, and just accept that the camera timestamps will be in UTC; the conversion's not hard, and for two hours a year it has distinct uniqueness advantages - those two hours in autumn where the clock runs over the same times twice.

And in future, buy better cameras.

Edit: advertising the wrong time from a dedicated, sacrificial, VM? Sure: set the clock wrong, and tell NTPD that the local clock can be trusted:

fudge 127.127.1.0 stratum 5
server 127.127.1.0

I'm sure saving money on the cameras makes you happy, but either you have a good business reason for needing these timestamped images, in which case you're torpedoing your own infrastructure, or you don't, in which case why bother?

Though as I hope I've shown, if you want these images timestamped for evidentiary value, there's a definite advantage to having them timestamped in UTC - unlike wallclock time, it's completely unique throughout the year.