Date: Wed, 1 Jul 2015 12:46:21 -0500 From: Leif Pedersen <bilbo@hobbiton.org> To: Mark Felder <feld@freebsd.org> Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@des.no>, "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: Leap Second Message-ID: <CAK-wPOjqZUPnWSbgXYt%2Bghu1BHUK7E=dUVU=oW8%2B0p7ywzN4Wg@mail.gmail.com> In-Reply-To: <1435758941.105242.312562265.3103CECB@webmail.messagingengine.com> References: <CAA3htvuv0Emy5SazXzYNZegKzS-Z4=tc3ua8Ca6GMgeTj99n7A@mail.gmail.com> <1435154274.964221.306546033.052903CD@webmail.messagingengine.com> <86bnfwxa4m.fsf@nine.des.no> <1435758941.105242.312562265.3103CECB@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Is there a reasonable way to enable awareness of leap-seconds while syncing with ntpd? That is to say, how can I get the system to include leap-seconds in calculating `date +%s`, without having `date` be off by 26[1] seconds? The default configuration produces incorrect results when computing historical time deltas. For example, the correct delta between midnights of 1970-01-01 and 2015-01-01 should be 1420070425 seconds, rather than 1420070400 seconds (wrong by 25 seconds). As our clocks continue to slip forward in time, we pretend 1970 was seconds later than it really was, and the recorded moment of the solar flare on 2003-11-04, for example, becomes wronger and wronger. Suppose I want the times I record to remain accurate to the second, and I want to be able to measure deltas between them using the usual approach (convert to epoch-seconds and subtract). Or suppose my task requires observing rates of events where having June 30 be broken by 1s matters. Then I want midnight of 2015-01-01 as reported by `date +%s` to be 1420092025 rather than 1420092000. I tried setting /etc/localtime to UTC including leap-seconds[2]. It works as I expected: `date -j 201501010000 +%s` reports 1420070425, a difference of 25s. However, ntpd continues to sync the clock (from pool.ntp.org) in ignorance of leap-seconds. That makes sense; I was pretty sure ntpd doesn't observe tzdata. Can ntpd undo the leap-seconds inserted by ntp.org? Or is there another NTP pool that would work for me? [1] The tzdata record starts with the 1970 epoch at 10s off of TAI. That is, one should imply an unrecorded leap of 10s at the end of 1969 when considering times between 1958 and 1970. This gets you from TAI to UTC. Refer to https://en.wikipedia.org/wiki/Leap_second . [2] I sort of cheated to accomplish this off-the-cuff. I copied /usr/share/zoneinfo/right/UTC from an OpenBSD installation. -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK-wPOjqZUPnWSbgXYt%2Bghu1BHUK7E=dUVU=oW8%2B0p7ywzN4Wg>