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

[Warner Losh <[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]
> >
> >
> >> 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.


> The TAI-UTC decision was made over two decades ago. We just have to live
> with the consequences.
>

Sadly, POSIX standardized TAI-UTC == 0. Or rather, put leapseconds
outside of the standard as something that's not worth considering since
it makes time code more complicated. Hence no unique time_t encoding for
UTC leap seconds. Or really, any encoding at all for leap seconds (which is
why I know of several ways to do it). There's language that can be taken to
mean a specific encoding, but there's contradictory language that says the
other language shouldn't be construed to dictate an encoding :(.

Oh the hundreds of hours I've wasted coping with this issue back
when I was building timing systems for a living.

Warner