> 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.

https://en.wikipedia.org/wiki/Leap_second#Workarounds_for_leap_second_problems

In particular, smoothed leap seconds:
https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/

> There is nothing fundamentally different about the precision required to claim a timescale based on TAI than one based on UTC

Indeed. It's worth considering what happened with character encodings.
In theory, each character set and encoding is its own well-defined
island. In practice, many programs receive bytevectors of unknown
provenance from files or over the network, and it's generally more
useful to handle them imperfectly than to refuse them.

A practical string representation is a bytevector tagged with an
encoding. A practical time representation is an integer or a real number
tagged with the timescale and timezone.

Two different operations are useful. One operation to _convert_ a value
from one character encoding, timescale, or timezone to another. Another
operation to _assume_ a new encoding, timescale, or timezone without
doing anything to change the underlying bytevector or number.

The concept of local time is ambiguous. An unspecified constant timezone
is different from a timezone that is intentionally variable.