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_d9s...@mail.gmail.com>: > |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso <stef...@sdaoden.eu> > |wrote: > |> Steve Allen wrote in > |> <20221028045813.ga20...@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@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
