Am Fr., 3. Jan. 2025 um 15:56 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> 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.

It is the very point of TAI to have a common frame of reference. Since
1977, it has measured the proper time at the geoid (which is an
approximation to sea level on the actual earth).  For exact time
measurements and applications like GPS and relatives, gravitational
differences are important. (In fact, one can even measure the heights
of mountains by comparing clocks.)

My point is that by fixing such a common frame of reference at the
very beginning (of the SRFI) all this physics can be avoided and only
algebra is left (which is easy to understand and which can be governed
through Scheme procedures).

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

For people coming new to the library and not having heard about TAI,
special leap seconds, etc., wording as precise as possible would be
great boon and would make the SRFI sufficiently self-contained.

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

The SI second as a unit of proper time (for some reference frame) is
the fundamental concept and should be at the base. A time interval can
be readily measured in seconds (or fractions thereof if floating point
values are to be avoided).  When an epoch is fixed, one can likewise
measure moments (of time) (on the TAI worldline).

Packaging seconds in weeks, months or years is a derived concept
(defined in terms of some arithmetic, which uses the length of days,
months and years and a date to be used for the epoch).  It can all be
seen as simple as the conversion between, say, metres and feet.  A
SRFI about that would not define what a metre is but could say that a
foot is 0.3048 metres and would provide conversion procedures.

Does it make sense?

>
> Perhaps this is also the problem Pierpaolo Bernardi was concerned about …
>
>
> Daphne
>