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

On Wed, Aug 3, 2022 at 12:37 AM Ulrich Windl <
Ulrich.Windl@rz.uni-regensburg.de> wrote:

> >>> 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.
>

Yea, CLOCK_MONOTONIC is a made up thing that is perfect for your running
program, and nothing else. It
won't be the same across reboots, it won't be the same on other machines
and the standard says that it doesn't
even have to be the same for all observers on the same system. Applications
cope with this today, and a leap
second (of either flavor) wouldn't affect it at all... Some systems will
even pause this clock during suspend
time.

The problem is with applications that use CLOCK_REALTIME and take evasive
actions of some sort
when they, for example, detect that a heartbeat is missing...

> > 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...

Nice.

Warner

> > 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
> >>
>
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>