> Date: Sun, 18 Jun 2006 12:29:46 -0400 > From: Danny Mayer <[EMAIL PROTECTED]> > Mike Bartman wrote: > > > 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. > > The protocol has no concept of timezones. To send anything outside of > UTC would violate the protocol and furthermore cause chaos to > timeservers everywhere.
When I wrote "code" I meant NTPD, not the protocol. NTPD can easily be aware of timezones, and DST. As I said, ours is and it works. > > 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. > > That's a deficiency of VMS. Not a deficiency...a difference. All the same capabilities exist, they are just done differently from the assumptions made in NTP. I agree that it was a poor design choice in VMS...as I said before. It makes things more complicated than necessary, irrespective of NTP issues, though it still works. > Such situation is handled just by the > clock-setting routine which would need to read a time-zone file or > environmental variable. I don't know how Jason implemented > this for VMS. Which "clock-setting routine" are you referring to? Changes are needed in a number of places in NTP's code to deal with this at the moment, or at least it was when I ported 4.1.1. It isn't all centralized in one place as you seem to be saying. The "get local system time" function has to be aware of timezones too, since the local clock is in local time...just for instance. NTP (the code, not the protocol) is written with the assumption that the local system time is GMT, and while this is the case in Unix, it is not on all systems. It would have made things simpler if NTP had been written with the assumption that the system clock was in local time and needed zone and DST adjustments. Then the Unix folks could just set their zone to GMT and no DST adjustment, and everyone would have been happy with no changes needed to the code to make it work for systems with local-time system clocks. > > 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). > > Actually that's wrong. It should be getting to 3am and setting it back > to 2am. You are incorrect. The time change in the USA happens at 2am, spring and fall. In the spring it goes from 1:59:59am to 3:00am. In the fall it goes from 1:59:59am to 1:00am. See the following links for confirmation. The first is the one the nist.gov site refers you to if you ask about DST: http://webexhibits.org/daylightsaving/b.html http://www.timeanddate.com/worldclock/clockchange.html?n=179 http://en.wikipedia.org/wiki/Daylight_Saving_Time#United_States http://wwp.greenwichmeantime.com/time-zone/rules/usa.htm > > 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. > > > You carefully note that you've just done it and don't do it > again. That's obvious. The problem is doing it in the right way so that a system crash doesn't cause amnesia. If you write something to disk (your only non-volatile storage on most computers I deal with) so you can't forget over a crash you have a potential race condition...if you write the data then change the time, you *could* crash after writing it but before the change completes (very small window of opportunity there, but Murphy lives...). If you change the time then write the data to disk, same thing. It would be really nice if there was a DST register in the system hardware clock...then you could look at it to see if you were or were not in DST at any time, and the hardware could do the 1 hour offset itself and the whole problem would be much simpler...but it wasn't done that way so we live with what we have. Putting the "flag" on disk at least reduces the risk window from an hour to a few milliseconds. > More importantly you should know from the NTP time what the time SHOULD be > irrespective of what the local clock says. Hmmm...need to think about this a bit...you may have a very good point there. If so, the whole "flag" issue evaporates, which would be really nice. > > 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. > > Correct and for that reason those things should ignore the local clock > and deal strictly with UTC so that the local time is really > irrelevant. They should, but they usually don't and we can't correct all the other software on the planet or tell our customers how to do things...not if we want to keep them as customers. So we make changes to the way NTPD works to accommodate their needs. Lest there be further confusion, these changes are additional capabilities and changes in the way the local system clock is set, not to the way the protocol is handled. -- Mike Bartman Process Software, LLC _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
