Table of Contents
Lunar Clock
NASA have been set the task of creating standard time zones for other worlds, starting with our own moon. This raised the thorny issue that on the moon (as almost everywhere else in the universe), the passage of time is different from what we experience here on Earth. Atomic clocks are the most accurate timekeepers we have, yet they run faster on the moon because time itself is passing at a faster rate. That's relativity for you.
I decided (at the gleeful urging of my father) to write a software clock that counters the effects of general and special relativity, in order to keep clocks on the moon synchronised with clocks on Earth.
The Program
The program would need to run as fast as possible, which requires two things: (1)simple code that (2)compiles down to machine language. I decided to use Go as my development language as it fulfils these requirements whilst enabling rapid development. I could have used assembly, but Go will optimise my code for me and save me a lot of time sweating over stuff such as memory management. Go (sometimes known as golang) was developed by Google. It has some quirks, but is generally a nice language to work with.
I have written the program, it is smart in that it provides a timestamp in nanoseconds that have elapsed since a given epoch. The epoch can be changed externally, negating the need to re-compile. There are various other configuration settings that can be set externally in a Windows-style ini file, including the number of nanoseconds to adjust time by, how frequently those have to be adjusted, and the point in time from which to apply modifications. This allows any period prior to relativistic effects to remain unadjusted.
In effect, this can be used on any world where it is feasible to have a computer. Actual timekeeping must be provided elsewhere, such as an atomic clock, which only needs to be trained to UTC once after it has been placed in-situ. After that, the program (henceforth called 'the server') will provide adjustments to negate relativistic effects.
The server currently runs as an RPC server, with a single function available that returns a simple timestamp in nanoseconds which is the current time adjusted. The computer the server runs on will need to be re-trained to the local timekeeper at regular intervals to avoid the drift that all computers suffer from.
The Future
Having written the software, and a test client program to fetch timestamps from it, what next? The software is pretty useless here on Earth, since there are no relativistic effects that need adjusting. They do exist of course, for example in aircraft and on high mountains, but re-training to an atomic clock is much easier for those systems and they already do it.
That brings to mind that most computer systems (i.e. operating systems) come with NTP clients to fetch the current time from a Network Time Protocol server/peer, and automatically update their clocks with the result. Why not take my software and refactor it as an NTP server? I'm looking into that now.