Re: NTP Configuration for DST?
- From: mayer@xxxxxxxxxxx (Danny Mayer)
- Date: Sun, 18 Jun 2006 16:29:46 GMT
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.
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. 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.
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.
I deal with both Unix and Windows code and at least they agree with each
other in this area. I used to write a great deal of VMS code so I am
very familiar with it. Bernie and I go back a long way, though neither
of us are at the same companies.
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).
Actually that's wrong. It should be getting to 3am and setting it back
to 2am.
No problem...until an hour later when it's 2amYou carefully note that you've just done it and don't do it again. More
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.
importantly you should know from the NTP time what the time SHOULD be
irrespective of what the local clock says.
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.
This is very simple. You look at the NTP time in UTC, apply the local
timezone rules and come up with what the local time SHOULD be. You don't
look at the local clock to figure out the time.
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.
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.
Like I said, it should get the UTC time and use that for database
timestamps so it doesn't have to deal with local variabilities.
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.
See above.
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.
There are ways to deal with this so you don't get into trouble.
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.
I used to use Steve Lionel's batch DCL code to reset my VAX clock twice
a year. It doesn't deal with other issues that you've outlined above.
Danny
-- Mike Bartman_______________________________________________
Process Software, LLC
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions
.
- References:
- Re: NTP Configuration for DST?
- From: Mike Bartman
- Re: NTP Configuration for DST?
- Prev by Date: Re: Horrible clock drift help
- Next by Date: Re: Horrible clock drift help
- Previous by thread: Re: NTP Configuration for DST?
- Next by thread: Re: NTP Configuration for DST?
- Index(es):
Relevant Pages
|
Loading
