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

[Ulrich Windl <[e-mail]>]

>>> Warner Losh <[e-mail]> schrieb am 19.10.2021 um 16:18 in Nachricht
<CANCZdfrT8TSo9BPZajT=[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.

Hi!

OK, I see that I have
/usr/include/bits/time.h:#   define CLOCK_TAI                   11
/usr/include/linux/time.h:#define CLOCK_TAI                     11

but it's not documented in "man clock_gettime", so I did not know about it.

In the kernel I found these helper functions:
/**
 * ktime_get_clocktai - Returns the TAI time of day in ktime_t format
 */
static inline ktime_t ktime_get_clocktai(void)
{
        return ktime_get_with_offset(TK_OFFS_TAI);
}

__timekeeping_set_tai_offset(struct timekeeper *tk, s32 tai_offset)

However I couldn't find out who ever sets tha toffset and how...

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

That file does not exist in my version 8-(

Regards,
Ulrich

> 
> Warner