On Sat, Oct 29, 2022, 11:49 AM Joseph Gwinn <joegw...@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_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 >
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
