[ntp:questions] Re: NTP Configuration for DST?

Danny Mayer mayer at ntp.isc.org
Sun Jun 18 16:29:46 UTC 2006


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 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. More
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



More information about the questions mailing list