Am Fr., 3. Jan. 2025 um 16:03 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> Another option, considering the current plans of the ITU and BIPM, might be to drop TAI and leap-second-endowed UTC entirely, as the Gregor library in Racket has done. Model a continuous civil time scale with 86,400 seconds in every day; let people come up with whatever fictions they like to represent the historical positive leap seconds when they need to do so (as the pre-SRFI suggests using ‘nearly accurate UTC’ for the rubber-second part of the UTC scale); and just hope a leap second never happens again.

I think this only appears to be conceptually simpler because, here,
time intervals are measured in days (so the length of a day comes in).
If they were just measured in seconds (using the opaque TAI reference
frame, for example), time measurement would not change because of leap
seconds or not. Only the conversion to a DMY format would be affected.

>
> Unfortunately, even if the plans aren’t delayed or changed yet again, we are heading for another leap second (the first negative one) around the end of this decade, and the current plan doesn’t foresee abolition until 2035, as far as I know.
> <https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-UT1-UTC&id=6>
>
>
> Daphne
>
> > On 3 Jan 2025, at 15:56, Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
> >
> > On 3 Jan 2025, at 15:08, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >
> >> I may have more comments soon, but here is one about the initial
> >> definitions as this proposed SRFI does want to do everything right if
> >> possible (which is a good thing IMO):
> >>
> >> Reading the definition of the TAI calendar, it can sound as if there
> >> were an absolute time (otherwise, the phrase "every 86,400 SI seconds"
> >> would not make sense). However, atomic clocks are precise enough to
> >> detect the derivations of Newtonian mechanics from special and general
> >> relativity. As there is no god-given absolute clock one has to take an
> >> arbitrary clock as a reference. A suitable reference is precisely the
> >> TAI clock, measuring seconds since the event that is called "1 January
> >> 1958" in the TAI calendar. Note that the phrase "at midnight on 1
> >> January 1958" does not make sense before the definition of any
> >> calendar (or, at least, has the danger of being a self-referential
> >> definition).
> >>
> >> With the TAI clock set as a reference, the TAI and the UTC calendar
> >> can then be derived through simple arithmetic.
> >
> > I’m not sure I understand.
> >
> > As a practical simplification, this SRFI (like many timekeeping applications) assumes that everything on planet Earth can be seen as having a common frame of reference. This is not true, but it’s usually considered close enough to the truth for most purposes.
> >
> > I agree there’s a risk of formal self-reference, but I wonder if you’re actually getting at a problem with the wording I was already concerned about, but had thought about in different terms than you seem to be using.
> >
> > The SRFI is not trying to do anything totally new, but rather merely to try to formalize in some useful way the informal notion of date and time for TAI as it’s already used, namely the notion that TAI (which ‘just ticks’, as John says) can be treated as if it were like UTC-based civil time, but going 37 seconds fast. Another formalization of this sort of idea is found in GPS time, which uses a count of weeks and a count of the number of seconds into the week, rather than the day-based version I use here.
> >
> > If you can suggest a better way to make that formalization, or some other way to relate the pre-SRFI’s calendar-system-independent notion of a ‘date’ to points in the TAI clock’s timescale, I would very much welcome it.
> >
> > Perhaps this is also the problem Pierpaolo Bernardi was concerned about …
> >
> >
> > Daphne
>
>