[LEAPSECS] article for Metrologia

[Joseph Gwinn]

General comment:

The POSIX standards which unix and variants follow uses a string time 
format that looks like UTC, but is not, because leap seconds are 
never applied.  This was done precisely because an isolated unix box 
had no access to leap-second information; this was the norm in that 
day, long before networks and GPS.

So, those faulty designers of yore had insufficient clairvoyance 
skills.

Joe Gwinn

On Sat, 29 Oct 2022 18:16:14 +0200, Steffen Nurpmeso wrote:
> 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)
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs