Here is a sketch of a low-level timezone and leap second access API.
This is primarily useful when doing arithmetic on general timestamps,
because there is no agreed-upon semantics for it.

The API uses vectors because binary search is commonly used to find the
relevant moment.

This sketch uses Δ to mean the difference between TAI and UTC in seconds
at a specific moment.

The implementation burden of such an API is minimal, because this
information has to be known to the implementation anyways. However, it
is quite a lot of extra procedures for very niche purposes, so this may
be a companion SRFI instead of being incorporated into this one.

_________________

     (leap-second-table)

Return the leap second table as an immutable vector. Leap seconds are
arranged chronologically. If the leap second table has not changed
between two calls to this procedure, the returned vectors should be eqv?.

     (leap-second? obj)
     (leap-second-moment leap-second)
     (leap-second-delta-tai leap-second)
     (leap-second-change leap-second)

Information about a leap second.

The moment (`leap-second-moment`) is the first second that has the
associated Δ. For example, for the leap second that occurred in 2017,
the moment is associated with July 1st, 2017 12:00:00 AM UTC. The moment
one second before that is associated with June 30th, 2017, 12:00:60 PM UTC.

The delta-tai is Δ.

If `leap-second-change` is +1, it is a positive leap second.

If `leap-second-change` is -1, it is a negative leap second. At the time
of writing, there have been no negative leap seconds, but it is possible.

      (timezone-changes timezone)

Return an immutable vector of fixed timezone changes for that timezone
in order. If the timezone has not changed due to a refresh, this object
should be eqv? each call.

     (timezone-change? obj)
     (timezone-change-moment tzchange)
     (timezone-change-to-dst? tzchange)
     (timezone-change-offset tzchange)
     (timezone-change-designation tzchange)

Information about the timezone change.

The moment (`timezone-change-moment`) is the first moment in the new
timezone. For example, for the 2026 EST->EDT transition would place the
moment at March 8th, 2026, 2:00 AM EST aka March 8th, 2026, 3:00 AM EDT.

`timezone-change-to-dst?` is true if the timezone change is considered a
change to Daylight Savings Time. It might be the case that a timezone
changes to "permanent" DST.

`timezone-change-offset` returns the clock time that is the new offset
from UTC.

`timezone-change-designation` returns the new abbreviated name of the
timezone.

      (timezone-earliest-offset timezone)

Return the offset for times before the first timezone change. Generally,
this is the local mean time offset for the city in question in this
timezone. For timezones that are fixed offsets from UTC, this is just
that offset.

      (timezone-earliest-designation timezone)

Return the designation for times before the first timezone change. For
actual locations such as New York, this is usually "LMT". For timezones
that are fixed offsets from UTC, this is usually a string that describes
the offset from UTC.

     (timezone-regular-change? timezone)
     (timezone-regular-change-to-dst timezone year)
     (timezone-regular-change-to-std timezone year)

Some timezones have scheduled changes that can be calculated. The first
procedure returns #t if there is such a scheduled change. The two
procedures return the STD->DST and DST->STD transitions for a given
gregorian year as timezone change objects, or #f if no information is
available (such as if there is no regular timezone change).

-- Peter McGoron