[LEAPSECS] article for Metrologia

Sat Oct 29 15:15:51 EDT 2022

On Sat, Oct 29, 2022, 11:49 AM Joseph Gwinn <joegwinn at comcast.net> wrote:

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

The problem is time_t can't encode a leap second uniquely, but leap seconds
had been a thing for ~20 years when the first POSIX standards came out. It
was more of a willful choice to disregard them entirely as a simplification
than lack of clairvoyance. At the time it didn't seem important but by the
late 90s the mistake was obvious to anybody who had to deliver a unix
system that pedanticly tracked time through a leapsecond or had to deal
with true UTC timestamps could attest... I found many rants in the early
2000s when I tried to ship my such system for LORAN-C timing system
refresh. It's the poster child in my mind for all the problems that I've
been mentioning that still aren't adequately addressed 20 years later.

Warner

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
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20221029/850d7a54/attachment.htm>