[VoiceOps] DST handling

[David Hiers]

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

David


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