The lunar clock has a new name: rtaps which stands for [R]PC [T]imestamp [A]djustment [P]rogram [S]erver. Yeah, I know, a bit contrived, but aren't all acronyms?

The code has now been published on GitHub at https://github.com/stroggprog/rtap and can be cloned using git or downloaded as a compressed zip archive.

I have decided not to turn the program into an NTP server, since that is non-trivial task. If someone thinks that would be a great idea (I no longer think so), they can take existing NTP code and amend it.

When a program requests the time from the system clock, what it is actually doing is requesting a timestamp that is valid at the moment when the timestamp is 'snapped'. By the time it reaches the requesting program, it is already out of date, or should at least be considered so. Generally, this isn't a big problem, but when requesting a timestamp with nanosecond granularity, it definitely is. Hence we need to think in terms of timestamps, not 'current time'.

The rtaps program will do one of two things: If it is provided with a timestamp, it will adjust it to counter the effects of relativity. If it isn't provided with a timestamp, it will request one from the system clock and adjust it.

At the moment, these two functionalities are provided through separate RPC functions, so there is no doubt about what happens when a program makes a call. Think of it as a way of managing expectations.

There is also a function available through the RPC interface to set the moment from which relativistic effects should be countered. For example, if the timekeeper (which may be the clock on the same machine as rtaps, or another server which provides NTP services) is retrained to be synchronous with UTC as it is experienced here on Earth, the time when this occurred needs to be recorded so only time after that moment is adjusted. That moment is called the private epoch. Calling the function SetPrvEpoch with a timestamp will set the private epoch to that time and write the time to the rtaps configuration file (in case of a restart).

As mentioned above, there is a configuration file. When the program is first run it will look for it, and if not found it will create it with sensible default values. If the configuration file is manually edited, the program will need to be restarted to load the new values. The only exception is the private epoch, which if changed via the SetPrvEpoch call will come into effect immediately.