LiveSplit atomic timing and TAI

Nobody has claimed this yet.

Forwarding this to here since its worth considering:

On Tue, 1 Nov 2022 16:56:40 +0000
opal hart 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]:
> \[2]:
> \[3]:
> \[4]:
>
> 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.

Start by reviewing livesplit-core's timing logic and the splits format, since the proposal does not name specific files or tests. Evaluate the TAI64N representation and the referenced tai64 Rust crate, then determine the compatibility and clock-synchronization implications. Done requires an agreed design for timing storage and any necessary splits-format changes.

Written by the indexing model from the issue text.