On 6 Jan 2025, at 00:10, Alex Shinn <xxxxxx@gmail.com> wrote:

> Note the small language already defines `(current-second)` as TAI
> using the Unix epoch of 1 January 1970, not 1958.  This agrees with
> at least the glibc CLOCK_TAI:
>
> https://www.man7.org/linux/man-pages/man3/clock_gettime.3.html
>
> I think redefining the epoch in the large language would just cause
> confusion.

1970 is a really crummy epoch for TAI-based applications, because the difference between TAI and UTC was non-integral at the start of the year.

The original version of the small language spec got this wrong by claiming the difference at this point was ten seconds, when in fact it was 8.000082 seconds. This had to be corrected by erratum. <https://github.com/johnwcowan/r7rs-work/blob/master/R7RSSmallErrata.md#:~:text=27.,-The%20claim%20in>

There are two possible epochs that make sense i.m.o.: 1958, when TAI and UTC started diverging; and 1972, since when the difference between them has always been an integer except during leap seconds. The pre-SRFI at the moment uses the former.

Note that the proposed API of this pre-SRFI does not actually expose when the TAI-based epoch defined by the spec is: it’s merely used there as an aid to defining how moments and timestamps interact, but both of those are actually accessed by Gregorian date and not by any count of seconds. The small language’s current-second isn’t part of this proposal anyway; it’s a lower-level primitive.

So the better question might be whether it might actually be worth simplifying the spec by pretending that |TAI − UTC| was always 10 before 1 January 1972, instead of pretending it was always 0 before 1 January 1958, partially undoing the change made to the small language specification by erratum.

Daphne