LiveSplit atomic timing and TAI

[DarkRTA]

Forwarding this to here since its worth considering:

On Tue, 1 Nov 2022 16:56:40 +0000
opal hart opal@wowana.me wrote:

Hi,

I don't have a GitHub account so I can't open an issue on either the
livesplit or livesplit-core repositories, but I wanted to run this past
you before deciding whether to implement it and mail a patch.

If you are unaware of TAI (which is completely understandable as it
receives little attention outside of cryptography circles and
"djb-like" software), basically it's a time-storage format and a
library that is strictly monotonic (only goes forward in time), does
not take into account leap-seconds or any other "natural" time
phenomena, and is thus suitable for a stopwatch such as is used in
livesplit. Bernstein compares TAI to UTC as well as "UNIX time" [1] and
gives an exact specification for the TAI64(NA) datatypes [2]. Laurent
Bercot has a C implementation of a library that handles TAI times [3],
and it seems there is a tai64 crate available for Rust as well [4]
although I have not vetted its source yet.

[1]: https://cr.yp.to/proto/utctai.html
[2]: https://cr.yp.to/libtai/tai64.html
[3]: https://skarnet.org/software/skalibs/libstddjb/tai.html
[4]: https://docs.rs/tai64/latest/tai64/

For livesplit-core this change would be fairly trivial to make; just
switch the core timing logic to use TAI64N as its representation and
make calls to the library to get, store, and manipulate these
timestamps. livesplit-core does no syncing with NTP; I personally argue
that it should stay this way, but I understand that LiveSplit targets
systems that may not be properly managed, systems where ntp or another
time synchronisation mechanism may not be run, systems where the clock
skew may be prominent enough to warrant a separate sanity check. I
don't believe that TAI addresses clock skew at all; its primary
guarantee is monotonicity, but that is more than enough to qualify it
over storing UTC timestamps.

Please let me know if you have any additional consideration, if you
think this is a fair task to work on, and if necessary, you may
re-distribute this message verbatim as a GitHub issue to prompt further
discussion on the matter.

---

Personally I think this might be worth doing, but we will need to consider how this will affect the splits format if it will even do so at all.

[CryZe]

TAI is definitely something I'm well aware of. UTC is indeed not quite the correct format, but we already don't use UTC when timing runs anyway, we use Rust's Instant, i.e. a non-calendar based monotonic timer. So this really only becomes relevant once we intend to synchronize with an atomic clock where ideally we should indeed use TAI over UTC.

[CryZe]

The tai64 crate seems to just provide some "notation" for TAI time stamps and it doesn't actually do any calculation with it. In fact it converts to UTC by doing absolutely nothing... which completely disqualifies this crate. I looked into how to do proper TAI handling on the various operating systems and it seems like:

1. No operating system provides functionality for converting from / to TAI.
2. Windows has a registry entry for leap seconds since 2018 (yes it's quite new), which is also completely empty atm because there haven't been any leap seconds since then.
3. Linux has the best support by providing functionality querying TAI directly and there's a file on the file system you can parse for all the leap seconds.
4. macOS has absolutely no support for TAI or leap seconds.

Here's a little prototype I wrote based on the time crate that provides a TaiDateTime:

https://github.com/CryZe/time-tai/blob/master/src/lib.rs

This could potentially be turned into a PR for the time crate.