I would agree and I am not a fan of leap second smearing.
A.) For an application that depends on an accurate frequency reference
smearing over 24 hours represents about a 11 ppm frequency shift. This
exceeds the tolerance specified for some audio/video applications.
B.) It is not standardized, so maybe it is a smear of maybe its not.
There is a lack of standards and that is probably the biggest source of
most leap second problems.
I have been searching for standards, documentation on how leap seconds
must be applied in local jurisdictions.
I find it strange that for time in local time zones the time points are
shifted by the UTC offset for all 86400 seconds of the day.
But that the one leap second is treated differently and is not shifted
by the UTC offset.
The consequence is that the leap second is being incorporated at
critical times of the day in many time zones.
While there is no perfect answer, it seems that Microsoft Azure servers
got it right for the last one, incorporating the leap second just before
midnight local time.
Control, on Time and in Sync
Stephen Scott
On 2018-07-20 08:03, Nero Imhard wrote:
scs...@eskimo.com schreef op 2018-07-20 11:35:
The question of what happens if you try to run a leapsec-aware
kernel downstream of a smearing NTP server is an interesting one.
My preferred answer is "Don't do that."
If that translates to "don't smear ntp" I could not agree more.
Smearing is catering to those who won't clean up their act,
causing trouble for those who try to do the right thing.
N
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
