> > As you note, NTP deals only with UTC. There is no > provision in the code > > for dealing with time zones or or standard vs. daylight > time and I would > > be extremely surprised if anyone on the development team would be > > willing to add such a thing. > > I would put it much stronger than that. This would go against > the whole > architecture of NTP. Timezone information including Daylight Savings > Time is a local phenomenon. That's what a GUI or even a command line > would display to the user. To change this would violate the > NTP protocol > and cause massive dislocation of reliable time distribution. Think > locally. Your clients get the NTP packets and turn them into > local time.
NTP uses UTC between servers and between servers and clients (same NTPD in both cases of course)...that doesn't mean that the code can't be aware of timezones or DST. Our port of NTP does exactly that, since unlike Unix, OpenVMS systems usually have the system clock set to local time, not UTC, and so there is no "at display time" conversion of the time and NTPD needs to know the local time to set the system clock properly. The time NTPD comes up with is converted to local time (using timezone tables and local DST rules) before the system clock is updated. We do this using zone and DST information already present in our products, but there's no reason that NTP couldn't do something similar out of the box. The only reason it doesn't, as far as I can see, is that this capability isn't needed on Unix, and most (all?) of the developers are unix folks. That and the problems of dealing with a system clock that runs on local time are not trivial. What sort of problems? Well, consider what happens in the fall in the USA...we set the clocks back an hour (most places anyway...there are exceptions). What does this do to NTPD? There it is, happily keeping the system clock set correctly, and the local time gets to 2am on the fall-back date. It looks at the DST table and realizes that it's time to back up an hour, so it changes parameters so that the local time is now calculated to be 1am and sets the system clock (sine we now appear to be off by an hour). No problem...until an hour later when it's 2am on the correct date to set the clock back an hour...again. Don't want to do that though...so how to deal with this? We call that hour "the twilight zone" and have to deal with it very carefully. Just setting a flag variable won't do it...what if the system crashes and comes up again after the step back, but before it passes 2am again? When you come up, what time is it? Are you or are you not in the twilight zone if the hardware clock time is between 1am and 2am on the step-back date? You need to know that to properly convert the UTC time you are getting from your time servers to the local time used by the system clock. There are other issues with NTP that we have to make changes to deal with. Clock stepping for instance...some of our customers can't tolerate sudden jumps in system time...particularly backward jumps (databases, or regulators, tend to become upset when a transaction finishes before it started)...so we had to add a "slewalways" option to prevent steps. When DST change happens it can take several hours for the "slew" to get the time back into synch with the rest of the world. Some customers can't tolerate being out of synch that long OR the stepping of the clock, so for them we added a feature to let NTPD spawn a sub-process to run a procedure that lets them restart their databases or whatever after the time change is complete...they use a batch job to shut things down just before the time change. There's also the issue of how big a time offset is allowable...to allow for DST shifts it has to be greater than 3600 seconds, which is much larger than the default setting NTP comes with. Dealing with time zones and DST is messy...but on some systems it has to be a part of NTP. There's no other way to use NTP on these systems. The developers of VMS and OpenVMS did a whole lot of things right...but the system time being set to local time is not one of them. -- Mike Bartman Process Software, LLC _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
