On 10 Nov 2024, at 16:02, Pierpaolo Bernardi <xxxxxx@gmail.com> wrote:

> I have to quibble about terminology:
>
> - TAI is a specialistic time scale. It's not just UTC ignoring leap seconds.

I don’t believe that it is ‘ignoring leap seconds’. But UTC is TAI with the *addition* of leap seconds – take them back out, and you have TAI by definition.

> - The conversion between TAI and UTC is not trivial (see reference
> SOFA), and of course it has a meaning only for times after the two
> time scales were established.

For the period since 1972, it is fairly trivial. My initial implementation (based on boxing a TAI moment into a UTC moment, as described in the previous mail) was maybe two dozen lines of Scheme code (plus a little bit more to actually parse the leap-seconds.list file). The ‘nearly accurate UTC’ suggested in the pre-SRFI allows the same trivial principle to be extended to the ‘tricky’ period.

It gets trickier during the actual period of a real, live leap second. We inevitably have to rely on the operating system to do the right thing.

> - Conceptually, unless you are a metrology laboratory with your own
> atomic clocks participating in the definition of TAI, you don't have
> access to any form of current TAI. UTC is what is distributed for
> civil use.

TAI is distributed indirectly through GPS time (always TAI minus exactly 19 seconds), as well as through the announcement of leap seconds by NTP servers. Operating systems make this information available directly (as CLOCK_TAI on Linux) and indirectly (the ntp_gettimex library function).

There is nothing fundamentally different about the precision required to claim a timescale based on TAI than one based on UTC; you don’t need a personal atomic clock. To claim otherwise is deep terminological nitpicking, amounting to an argument that any effort at timekeeping outside of a laboratory is incoherent with the time standards. The time standards are made to be put to practical use, not gazed at in a glass display case.

> - IMHO, for the standard library of a programming language it is too
> much to require users to understand the subtle differences between TAI
> and UTC. Usually, these are things we want to know as little as
> possible. Unless one is an astronomer, in which case they will use a
> specialistic external library (see reference SOFA)

This was decided already well over ten years ago – in my view, correctly – in favour of TAI as the standard Scheme time measurement scale.

See this thread <https://scheme-reports.simplelists.com/scheme-reports/msg/25741312/> which continues here <https://scheme-reports.simplelists.com/scheme-reports/msg/25741852/>.

See also the page which Arthur linked: <https://geometrian.com/programming/reference/timestds/>
The pre-SRFI’s notion of ‘timestamps’ for civil use (worldwide) and ‘moments’ for measurement is essentially consistent with the recommendations of this page. (A moment can be as scientifically accurate as necessary – someone who does have an atomic clock could probably use this library to represent their readings from it.)

> So, if one just wants a time scale useful for everyday tasks which
> avoids the nuisance of leap seconds, it would be better to simply use
> the number of SI seconds since an epoch.

That is, for all practical purposes, TAI – or rather the ‘TAI calendar’ as I have defined it in the pre-SRFI.

Daphne