They're reasoning is also flawed. They say that ntpd reads the standard leapseconds file and chronyd doesn't. They're correct in that, but chronyd gets the same information from the zoneinfo DB. All they had to do was add "leapsectz right/UTC" to their chrony.conf.
-Dustin On Thu, Mar 19, 2020 at 10:38 AM Judah Levine via LEAPSECS <leapsecs@leapsecond.com> wrote: > > There are troubling aspects about the facebook method: > 4. The facebook method of applying the smear *after* the leap second is > the most troubling aspect of the process. It is not consistent with the > definition of UTC or with the other smear methods that apply the smear > before the leap second. The question of whether smear methods are "good > enough" has no absolute answer. They are very definitely *NOT* good > enough to satisfy the European rules for time-stamp accuracy of > financial transactions, and these rules are likely to be adopted by the > regulators in the US in the foreseeable future. A client system that > sends requests to servers with different smearing algorithms will be > really confused in the vicinity of a leap second. In the worst case, the > client may reject all of the replies as requiring a time-step that > exceeds some maximum threshold, such as 128 milliseconds. _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
