[VoiceOps] DST handling

David Hiers hiersd at gmail.com
Fri Nov 6 12:03:34 EST 2009

I may not have been clear before, but that's pretty much what we do.


On Fri, Nov 6, 2009 at 8:12 AM, Colin <zavoid at gmail.com> wrote:
> Why aren'y you recording all cdr's in GMT and adjusting call log displays as
> needed based on where the customer wants to see the call log in?
> Colin
> On Nov 6, 2009, at 11:06 AM, David Hiers wrote:
>> 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
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops

More information about the VoiceOps mailing list