From owner-freebsd-security@freebsd.org Wed Jul 1 17:47:03 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D6CA9923D6 for ; Wed, 1 Jul 2015 17:47:03 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C95922097 for ; Wed, 1 Jul 2015 17:47:02 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: by widjy10 with SMTP id jy10so64303990wid.1 for ; Wed, 01 Jul 2015 10:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TF4sTVtfqke7jqq9JeGNidtq3PW0JQMAgj0aCzNinck=; b=ffztSj6vB8IqADIJr45lU1jYOKakHlrh7d/mlz3MWbyJ2YJE1utSLW/+yvbnnPoglI 02VbLAYx4MT5QVn8pTd5aIP8aFONJEOK5WOeJj6MBut704T0TieehQAEBSsb4BWv8p1Q AFYAxNMmv7BTD938oCQOFM0fgWfzkQGJQBtxMrIk3mV0qBbPGQyduaT9qbT9u+z+2SOm 1/7ElytEim+tKuHd1MEvQRgLKKRmglIlQRl7nLXzzTJv/zM//FWufOeaXEoYkqelKzio frF8sfhJqh0oTyYzhLZ07RjLprS9nexnnteau+0hY/34JQLDaw6e5l4EH+f8nL8gcXZt wn2A== X-Gm-Message-State: ALoCoQlxoXLuqenZDiKTtBvsLbVp8jvWZ+0DLaCD2SQ9mjTIvGVH5WCgCHCLrDZBxxac2zRK1nFF X-Received: by 10.180.100.74 with SMTP id ew10mr48034211wib.12.1435772821184; Wed, 01 Jul 2015 10:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.159.207 with HTTP; Wed, 1 Jul 2015 10:46:21 -0700 (PDT) X-Originating-IP: [68.178.93.3] In-Reply-To: <1435758941.105242.312562265.3103CECB@webmail.messagingengine.com> References: <1435154274.964221.306546033.052903CD@webmail.messagingengine.com> <86bnfwxa4m.fsf@nine.des.no> <1435758941.105242.312562265.3103CECB@webmail.messagingengine.com> From: Leif Pedersen Date: Wed, 1 Jul 2015 12:46:21 -0500 Message-ID: Subject: Re: Leap Second To: Mark Felder Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , "freebsd-security@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 17:47:03 -0000 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