[VoiceOps] DST handling

[David Hiers]

My system clocks are all within 1 second of time.gov just days after
the DST change.  We made the jump all at once, got double the number
of hourly CDR files for an hour, and will get no CDR files for an hour
in the spring.  Don't think that we did anything special...

What do your clocks look like today?

We show start time and duration for customer-facing reports.

David


On Thu, Nov 5, 2009 at 9:28 PM, James Hess <mysidia at gmail.com> wrote:
> The NTP protocol uses UTC as reference time;  UTC  is a time zone that
> has no DST changes.      If the real-time clock on a device is kept in
> a local time, the NTP implementation on the device has to translate
> to UTC  and back.
> There should be no difference in the calculated UTC time before, or
> after time change  caused by DST.
>
>
> On Thu, Nov 5, 2009 at 4:34 PM, Jonathan Thurman
> <jonathan at thurmantech.com> wrote:
>> On Thu, Nov 5, 2009 at 3:16 PM, David Hiers <hiersd at gmail.com> wrote:
>>[...] It is the responsibility of the operator to get the clock in
>> sync to start with, then NTP will adjust for the natural drift.
>
> Adjusting clocks by large amounts by default can be dangerous.. there
> might be an accident on another NTP server.    An evil hacker who can
> forge NTP packets may have cracked an expired  Kerberos TGT,   or  may
> desire that a server execute a certain cron job over and over
> again....
>
> If the time is off by less than 128ms,  NTP will slew.  If it's off by
> more than that NTP will often step  (make a large error correction)
> instead.
> But there is a "panic"  limit  to the error corrections. If the clock
> is too far off,  NTP will simply exit.   You can change the number of
> seconds, or set it to be unlimited  [at own risk]:
>
> tinker panic 0
> ...
>
> In certain *ix distros, you also get stepping at NTP startup according to
> entries made in an  /etc/ntp/step-tickers
>
>
> --
> -J
>