bug#21912: TAI<->UTC conversion botches the unknown

[Mark H Weaver <mhw@netris.org>]

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