What is more, there are no TAI<->UTC conversion tables from before 1961
(when UTC began) and probably never will be.  There was heated debate in
the R7RS-small working group, and we finally settled on a compromise:

(current-second) [r]eturns an inexact number representing the current time
on the International Atomic Time (TAI) scale. The value 0.0 represents
midnight on January 1, 1970 TAI (equivalent to ten seconds before midnight
Universal Time) and the value 1.0 represents one TAI second later. Neither
high accuracy nor high precision are required; in particular, returning
Coordinated Universal Time plus a suitable constant might be the best an
implementation can do.

I now see that the "ten seconds" is incorrect, and I am filing an erratum:
the correct figure is 4.2131700 seconds per <
http://maia.usno.navy.mil/ser7/tai-utc.dat>.

On Sat, Oct 20, 2018 at 6:25 PM Mark H Weaver <mhw@netris.org> wrote:

> Zefram <zefram@fysh.org> writes:
>
> > Guile ought to be aware of how far its leap table extends, and signal
> > an error when asked to perform a TAI<->UTC conversion that falls outside
> > its scope.
>
> I sympathize with your preference to raise an error rather than return
> invalid results, but unfortunately I don't think this proposal is really
> practical, given the SRFI-19 API.  The main problem is that, although
> it's not specified in the document, the SRFI-19 reference implementation
> uses UTC for all julian days, modified julian days, and dates.  For
> example, 'time-tai->date' and 'time-tai->julian-day' include an implicit
> conversion to UTC.
>
> As a result, if we were to adopt your proposal, it would never be
> possible to print a date more than 6 months in the future, and for users
> of stable distributions such as Debian, it is not be possible to print
> the current date.
>
> We need a way to print future dates.  In theory, we could print future
> dates in TAI without the leap second table, using the convention of
> printing TAI dates as in <https://cr.yp.to/proto/utctai.html>, but
> that's not what SRFI-19 does, and it has no API to support that way of
> printing TAI dates.
>
> Also, it's debatable whether it's desirable to print future dates in TAI
> this way, since in the far future the times will drift far away from
> mean solar time, and the calendar will eventually drift from the usual
> alignment of the solar year to the months on the calendar.
>
> So, I think this is a valid issue, but I don't see how it can be
> addressed within SRFI-19.  I would need to be addressed in a new SRFI,
> and even then it's not clear to me what's the right way forward.
>
> What do you think?
>
>     Regards,
>       Mark
>
>
>
>