1

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 ;)

Tom
  • 133
  • 1
  • 4

1 Answers1

4

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.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • while I agree with your statements regarding it being a bad idea on an otherwise used system, would you be able to describe how to go about it, when wanting to do that in a dedicated VM? Or maybe there's a why to lie only to certain IPs (all my ip cameras are in their own dedicated IP range). "buy better cameras": well, yes, of course that is a solution. actually I have several "better" cameras, with brand names on them, where the time isn't an issue. but I also like the chinese no name cams, as they cost about a quarter, have great image quality, and only suffer from certain hiccups like DST – Tom Oct 03 '14 at 07:42
  • yes, I will run them on UTC -- just wanted to know the answer anyway – Tom Oct 04 '14 at 08:04
  • I am not sure this is the same thing as serving DST via ntpd. This answer is essentially "serve UTC + TZ Offset and pretend its just UTC." It is not clear how your solution would handle EST to EDT transitions. Grammar Nazi Note: There is no such thing as "partially unique" and therefore "completely unique" is equally silly. There are no "levels of uniqueness" something is either unique or it is not. – dfc Oct 17 '14 at 07:50
  • I agree, it's not; it's as close as the OP can reasonably get, given that NTP is designed not to work this way. My answer doesn't handle the offset at all, it simply serves wallclock time as if it were UTC, and the cameras pick it up. Twice a year, they'll have a sudden one hour clock offset that they'll have to deal with; that is true for **any** device that can't handle the shift into and out of summer time. You are right about uniqueness; I'd edit, but I'm opposed to trivial fixups on older content, see eg my comments on [this meta answer](http://meta.serverfault.com/a/6594/55514). – MadHatter Oct 17 '14 at 08:29