[LEAPSECS] article for Metrologia

[Steffen Nurpmeso]

Warner Losh wrote in
 <CANCZdfqhhoTPj-3EnAq=CExwUdwxojV3JH0obzYf1-0_d9Sfvw at mail.gmail.com>:
 |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso <steffen at sdaoden.eu>
 |wrote:
 |> Steve Allen wrote in
 |>  <20221028045813.GA20487 at ucolick.org>:
 |>|On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
 |>|> Levine, Tavella, and Milton have an upcoming article for Metrologia
 |>|> on the issue of leap seconds in UTC
 |>|>
 |>|> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
 |>|
 |>|sorry, stray character appended to my cut and paste
 |>|
 |>|https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
 |>
 |> That "increasing number of applications" all through the document
 |> makes me angry really.  I find it astonishing to read that there
 |> are digital clocks that cannot display a second 60 and all that.
 |> This is just another outcome of the trivialization and
 |> superficialication all around.  You need a reliable source of
 |> time, use TAI; or distribute the offset of UT1 and UTC
 |> permanently, best TAI, too.  so that changes can be detected.

I mean yes, it may be that many languages provide a complete set
of functions, time spans and whatever is needed to deal with time
properly.  I have not really looked, and my C++ is as of pre Y2K,
more or less (but completely regarding the library that grew
enormously, that much i know).

For plain ISO C there is nothing, and when you refer to the
"right" zoneinfo, then i cannot deal with this, let alone easily,
in a multithreaded environment, etc.
This is a miss of ISO C that should have been addressed maybe
already in the first real version beyond the labratory where it
was created, instead of beating onto Ritchie's nerves for mess.

 |If you deal with time in TAI, then you must have a perfect source of leap
 |seconds due to the de-facto requirement that times be presented in UTC.
 |That's the biggest problem with using TAI + the 'right' files. If you don't
 |know
 |the offset when the system starts, then fixing it later can be hard.
 |
 |The truth often is that UTC is available, and if you're very lucky, \
 |you have
 |a source of leap seconds that's in-band and as-reliable as UTC in a timely
 |manner. If you aren't lucky, then using TAI is a non-starter or requires
 |several orders of magnitude more effort to setup a distribution system of
 |it and you're often left with the conversion to UTC problem.

Yes.  It was a design fault.  Why should machines be driven with
a time scale designed for human life?  Instead a machine time
should be distributed with the necessities to derive the (a) human
time from it.  But that ship has sailed with the satellites and
NTP.  So then a few bits have to be found to include the offset
permanently.  This could long have happened.  But changing a human
timescale to make badly designed machines happy, or only making
bad software happy that unrolls bad code because of missing
support in standard libraries.  I would not do this.


 |> Distribution of leap seconds into time and date applications is
 |> a problem.  Clock calculations with UNIX epoch are all wrong given
 |> the current semantics except in the current (leap) era.
 |> Does this change if leaps are removed in the future.  For the
 |> past.  We need a reliable clock, which is TAI to me, and we need
 |> the leap second table in order to generate graceful dates in the
 |> past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
 |> 2023-06-28 ... UTC.
 |
 |Yes. Having two time scales is a problem due to the need for perfect
 |knowledge
 |of both parts. given the current issues that persist in gaining leap second
 |knowledge, that makes TAI unreliable.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)