Date: Wed, 01 Jul 2015 08:55:41 -0500 From: Mark Felder <feld@FreeBSD.org> To: =?ISO-8859-1?Q?Dag-Erling=20Sm=F8rgrav?= <des@des.no> Cc: freebsd-security@freebsd.org Subject: Re: Leap Second Message-ID: <1435758941.105242.312562265.3103CECB@webmail.messagingengine.com> In-Reply-To: <86bnfwxa4m.fsf@nine.des.no> References: <CAA3htvuv0Emy5SazXzYNZegKzS-Z4=tc3ua8Ca6GMgeTj99n7A@mail.gmail.com> <1435154274.964221.306546033.052903CD@webmail.messagingengine.com> <86bnfwxa4m.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 1, 2015, at 08:47, Dag-Erling Sm=F8rgrav wrote: > Mark Felder <feld@FreeBSD.org> writes: > > I'm not an expert on the leapsecond operation, but if I understand it > > correctly there are two ways a system can be notified of a leapsecond: > > via a tzdata update or through NTP. >=20 > Answering a bit late, but no: in practical terms, only NTP works. Better late than never :-) > Recording leap seconds in tzdata breaks POSIX and a lot of assumptions > in existing code, not only on the day a leap second occurs but at any > time in history after at least one leap second has occurred. >=20 Yeah, I think it's pretty obvious now that doing leapseconds in tzdata is a bad idea -- worse than leapseconds themselves maybe? :-) > > 1) FreeBSD server unaware of leapsecond due to no tzdata entry and not > > synced to NTP ends up 1 second off >=20 > A server which is not synchronized with a reliable external source will > end up a lot more than one second off regardless of leap seconds > because it relies solely on onboard RTCs and oscillators which are both > inaccurate and imprecise. Clock drift will be measured in seconds per > week and vary depending on CPU load, disk I/O, the phase of the moon and > your dog's horoscope. >=20 I was ignoring that bit, but it's worth pointing out to the readers. I should have worded it "...will be one *more* second off" :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1435758941.105242.312562265.3103CECB>