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
