[LEAPSECS] article for Metrologia

[Warner Losh]

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.


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.


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

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20221028/ace9d911/attachment.htm>