Re: [Ntp] Leap second

Warner Losh <imp@bsdimp.com> Fri, 24 January 2020 15:38 UTC

Return-Path: <wlosh@bsdimp.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED440120090 for <ntp@ietfa.amsl.com>; Fri, 24 Jan 2020 07:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVUlG0l2_QNJ for <ntp@ietfa.amsl.com>; Fri, 24 Jan 2020 07:38:01 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D46120048 for <ntp@ietf.org>; Fri, 24 Jan 2020 07:38:01 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id s187so2402266qke.8 for <ntp@ietf.org>; Fri, 24 Jan 2020 07:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E2mQdaSsIq+7AA0fMFvpVIbc/vOPAcG/WOevxv2WvGI=; b=repM+2jXIqXr0DhaXPdBoa84Ts5m7rqXAAqJebjiC8+BErx0OdQixqqBSdlD6jUMFI SKUES1OwxDv4EEKuvUNZ9T982xK1gzf30GsoLi65e0HAo/0N15gIgTpCYEzHw4IHTbL2 PdJyoYNtg4CeU/mfZYMIL0ZMmy/NXO1vnlvmBqRS1sABDGyaFrDixhcLh9zSKhTufNUj o1v92wahr6Qd2EeQONUxC4MHw0YvB6UBXsCq7S7HVS7YhGP5kZDkAJnTtrFK7DIOUanh abdEVVH7b9NlwySJ3zRlq7W/eaoSxGYMXnMZJrb682EHP6gCFsiQwS8fBXd5hKVuYhxB tqaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E2mQdaSsIq+7AA0fMFvpVIbc/vOPAcG/WOevxv2WvGI=; b=pEKqxjqMU958VplB2x6Y8tG6pJtizYSoUxUs8VUdqXWG+53bmrQGKdONIFVSi516jp nRNtdvCN7UZu/6uDczPiXZ2dNI72Q8dd2BD4SEgUkcoHuwxWaDpioH+8GAutkklNJMmN 7/cm4OxCgb8V5qFhxnSJEqIcaP75dFf8ym1WDrn8qaNG0OE9kh1I0I0E2zAPUJcS7xBq EtS741wXuIREOu7oIeC4XOAKkLtEjkEF9d7Sd97TJeMslZtwlkZ92Vzry/Pv9x6V6hLw n1yVNq5TPoUpIUTnhvUF4d5yCfC2+UwbPmPAflMOsu7H7kZEUpnye0eHuOs/12JY2O5t N3FA==
X-Gm-Message-State: APjAAAVLQFqsYP+c8Z8HrJX3rFfZ1CCrY2G144fFV957D+WrC9q8S6JE jJb3suyqlSoQ5dvdxQzYk//zQSV61KOOuk6457WBiw==
X-Google-Smtp-Source: APXvYqzEq3osM35rW5bM0ngj8enDZ+jZDNcmOkSMUDVxh2b1BBGc43p8yRnKYFdrs4lK0C4BzmEM3feQw6fNG73TpLc=
X-Received: by 2002:ae9:c106:: with SMTP id z6mr3098314qki.380.1579880279822; Fri, 24 Jan 2020 07:37:59 -0800 (PST)
MIME-Version: 1.0
References: <20200123235232.BB54440605C@ip-64-139-1-69.sjc.megapath.net> <alpine.DEB.2.20.2001241435170.24409@grey.csi.cam.ac.uk> <F3DFEC05-3701-40D1-82B1-D66648814DD9@email.arizona.edu>
In-Reply-To: <F3DFEC05-3701-40D1-82B1-D66648814DD9@email.arizona.edu>
From: Warner Losh <imp@bsdimp.com>
Date: Fri, 24 Jan 2020 08:37:48 -0700
Message-ID: <CANCZdfpm0d0Ngt5ACLy4ZFyRMwvAVFbP5h9K08wkPENmXAnd8g@mail.gmail.com>
To: "Seaman, Robert Lewis - (rseaman)" <rseaman@email.arizona.edu>
Cc: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dde8f3059ce48a46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/r9sU8pdAydCXvnS6TFqqDTGFpas>
Subject: Re: [Ntp] Leap second
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2020 15:38:04 -0000

Just a reminder that neither NTP nor POSIX admit that leap seconds exist
wrt their time stamps, only via some auxiliary data path are they
grudgingly communicated. Since neither of them have a unique encoding for
the leap second, we're left with a repeated label for two seconds, or some
kind of 'gap' where time stands still (which effectively repeats the second
or, viewed in the frequency domain, has a large frequency shift).

UTC is a flawed standard that almost nobody implements completely
correctly. It was promulgated without due thought and care (the record is
clear on this) and now we're stuck with its new way of counting time
(nobody had 61 seconds in a minute before UTC). While it's handy to keep
the clocks aligned to the funky direction the earth points in, and thus
keep telescopes pointing well enough to find the stars they are looking
for, the number of places where people have botched translating it into a
useful implementation remain large and stand as a body of evidence that
points out its flaws... Sadly, we're stuck with it. The least bad option
for coping seems to be introducing a frequency error to paper over leap
seconds, at least judging by what industry does...

Warner

On Fri, Jan 24, 2020 at 8:17 AM Seaman, Robert Lewis - (rseaman) <
rseaman@email.arizona.edu> wrote:

> Just a reminder that UTC does not have repeated seconds, whatever POSIX
> says, or NTP implements. Seconds are interposed (or elided) as needed. UTC
> second number 61 in that minute is distinct from second number 60. Or
> second number 59 of one minute is immediately followed by second number 1
> of the next. If you want different behavior, define or adopt a different
> time scale.
>
> Rob Seaman
> Lunar and Planetary Laboratory
> University of Arizona
> --
>
> ´╗┐On 1/24/20, 7:48 AM, "ntp on behalf of Tony Finch" <ntp-bounces@ietf.org
> on behalf of dot@dotat.at> wrote:
>
>     Hal Murray <hmurray@megapathdsl.net> wrote:
>     > Warner Losh said:
>     > > NTP timestamp repeats the last second of the day. Once without the
> leap bit
>     > > set and then again with it set.
>     >
>     > Which bit is that?  I don't know of a single "leap bit" in the
> header.
>     >
>     > There is a 2 bit header field with: normal (no leap), and add+del
> (leap
>     > pending) states.  The 4th state is used for non-in-sync.  Assuming
> you meant
>     > "bits" rather than bit, then the on-off is backwards.  I expect it
> to be
>     > sending leap-pending for most of the day, then send normal (no
> leap-pending)
>     > for the repeated last second of the day.
>
>     My understanding is that the leap indicator bits are not synchronized
> with
>     the leap second, so they can't be used to disambiguate the repeated
>     second.
>
>     https://mailarchive.ietf.org/arch/msg/ntp/5KD48S2BFAMemNx99zQSB83hOJ8
>
>     This isn't specified in the NTP RFC, but I believe the way it works in
>     practice is that ntpd tells the kernel about the leap indicator bits
> using
>     ntp_adjtime(STA_INS), then continues with the same leap indicator
>     bits through the leap second until a subsequent ntp_adjtime() returns
>     TIME_WAIT, at which point the leap indicator bits are cleared. When
> this
>     happens is related to ntpd's polling interval, and not coupled to the
> leap
>     second at all.
>
>     Tony.
>     --
>     f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
>     democracy, participation, and the co-operative principle
>
>     _______________________________________________
>     ntp mailing list
>     ntp@ietf.org
>     https://www.ietf.org/mailman/listinfo/ntp
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>