Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

[Warner Losh <[e-mail]>]

On Tue, Oct 19, 2021 at 2:05 AM Ulrich Windl <
[e-mail]> wrote:

> >>> Warner Losh <[e-mail]> schrieb am 18.10.2021 um 16:54 in
> Nachricht
> <CANCZdfqzduC=9oxhqgNJdxUqveRp=[e-mail]>:
> > On Mon, Oct 18, 2021 at 8:10 AM Danny Mayer <[e-mail]>
> wrote:
> >
> >>
> >> On 10/18/21 1:49 AM, Ulrich Windl wrote:
> >> >>>> Doug Arnold <doug.arnold=[e-mail]>
> schrieb
> >> am
> >> > 15.10.2021 um 17:53 in Nachricht
> >> > <
> >>
> >
> [e-mail]
> > m
> >> >
> >> >
> >> >> Hello James,
> >> >>
> >> >> I agree that leap smearing is a clumsy and dangerous way to avoid the
> >> >> complication of correctly handling leap seconds in distributed
> database
> >> >> software.  And if it was up to me all IT equipment would use TAI for
> all
> >> >> timing except what is displayed to humans.  But it is not up to me.
> The
> >> >> people who are making the call tell me that they believe that leap
> >> seconds
> >> > is
> >> >> less bad than either moving everything from UTC to TAI, or writing
> and
> >> >> debugging database software that manages leap seconds properly.
> >> >>
> >> >> So given that state of affairs.  What do we do?
> >> > Hi!
> >> >
> >> > I guess the standard C library needs new functions to get the correct
> >> time
> >> > first ;-)
> >> > time_t has a problem
> >>
> >
> > Yes. The fundamental problem is that POSIX says there's no such thing
> > as leap seconds in time_t. They don't exist, they don't have a unique
> > encoding. And any way you represent them (there's at least 3 I know
> > of) is ambiguous. This is the reason why smearing is a thing.
> >
> >
> >> > Amazingly gettimeofday can use struct timezone, while clock_gettime()
> >> can't.
> >> > So adding the TAI offset to struct timezone would not help much.
> >>
> >
> > Look at the 'right' timezones.
> >
> > But clock_gettime passes in the 'clock' that you want. You can ask for
> > TAI time, but you still have the ambiguity.
>
> In my version of Linux (rather "new" regarding "industry standards") such
> a flag does not exist.
>

clock_gettime(CLOCK_TAI, &ts);

CLOCK_TAI isn't standardized by POSIX, but it definitely exists in Linux
and has for 15 or 20 years.

Whether or not the system has the requisite information to give it to you
is another matter, but the clock is well defined and absolutely exists.
See Documentation/core-api/timekeeping.rst for its definition.

Warner