[Ntp] Antw: [EXT] Re: Negative leap‑second?

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Wed, 03 August 2022 06:36 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 C9070C16ECA2 for <ntp@ietfa.amsl.com>; Tue, 2 Aug 2022 23:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvmMJQwudb9p for <ntp@ietfa.amsl.com>; Tue, 2 Aug 2022 23:36:54 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e7a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D729EC13180D for <ntp@ietf.org>; Tue, 2 Aug 2022 23:36:52 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8F39A6000061 for <ntp@ietf.org>; Wed, 3 Aug 2022 08:36:47 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id 766F3600005F for <ntp@ietf.org>; Wed, 3 Aug 2022 08:36:47 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 03 Aug 2022 08:36:47 +0200
Message-Id: <62EA177E020000A10004C0F3@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.0
Date: Wed, 03 Aug 2022 08:36:46 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Daniel Franke <dfoxfranke@gmail.com>, mayer@pdmconsulting.net
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <b023985d-76c3-c6b9-3b5b-f10b3cabd2f5@pdmconsulting.net> <CAJm83bAZgW=xgkO8BAW8HFTsSkGfdQKjkdQnfkyNWRAHdVTB3w@mail.gmail.com>
In-Reply-To: <CAJm83bAZgW=xgkO8BAW8HFTsSkGfdQKjkdQnfkyNWRAHdVTB3w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/S3k4f43zwApnN5rSEYxntOCOeBA>
Subject: [Ntp] Antw: [EXT] Re: Negative leap‑second?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Wed, 03 Aug 2022 06:36:57 -0000

>>> Daniel Franke <dfoxfranke@gmail.com> schrieb am 03.08.2022 um 01:19 in
Nachricht
<CAJm83bAZgW=xgkO8BAW8HFTsSkGfdQKjkdQnfkyNWRAHdVTB3w@mail.gmail.com>:
> I think predictions of a negative leap second are very premature, but I
> have fewer worries about a negative one than about a positive one. I've
> reviewed quite a lot of leap second handling code and never encountered any
> that gets the positive case right but the negative case wrong; programmers
> clued into the issue at all and generally clued in enough to know that
> negative ones are a possibility. What makes me *less* worried about
> negative leap seconds (rather than just not-much-more worried) is their
> effect on leap-second-naive code: they make POSIX time jump forward rather
> than backward. Lots of code out there wrongly assumes that POSIX time can
> never jump backward. Code that assumes it can never jump forward would get

Well, there are probably also assumptions that CLOCK_MONOTONIC never jumps back (it could when the device is restarted).
It depends how the timestamps are used.

> broken every time someone every time someone suspends their laptop or
> pauses their VM or just puts their OS scheduler under a lot of load.

BTW: Recently I migrated some Linux machines to VMware where the assumption is that the RTC runs on local time (while a standard Linux installation assumes it runs on UTC).
On boot the time was two hours (CEST in effect) ahead and was corrected in a rather brute way (jumping back):
An hour later a "journalctl -S <10 minutes before)" still had an interesting output...

Regards,
Ulrich

> 
> On Tue, Aug 2, 2022, 19:06 Danny Mayer <mayer@pdmconsulting.net> wrote:
> 
>> Apparently the earth's rotation is speeding up:
>> https://www.timeanddate.com/news/astronomy/shortest-day-2022 
>>
>> If we have to subtract a leap-second I think we will see failures, since
>> this is rarely if ever tested.
>>
>> Danny
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp 
>>