Table of Contents
Rust
I've been learning Rust (the programming language, not the online game), and as I get to grips with it's idiosyncrasies, I'm loving it more and more.
I've currently set myself the task of reproducing the functionality of my Mars Clock, which I wrote for the Raspberry Pi. The Mars Clock is intended as a permanently running piece of software in a hardware configuration to display the current time anywhere on Mars, using the Martian Calendar. It also displays information about experiments if you choose a location where an experiment landed (pancake or soft-landing both count). The display is highly configurable. You can read more about it on the Mars Clock page.
I'm not intending to reproduce the entire functionality of the clock, but provide sufficient functionality that it can keep accurate time and manage things like leap-second updates.
Tasks
The program needs to conquer some things that are inherently difficult to anyone who hasn't tackled them before, such as myself.
- The program will be a GUI app, so straight off, tackling GUI
- Creating cross-platform applications, so it needs to run on Mac, Windows, Linux-x86, Linux-ARM, Web
- Parsing IERS Bulletin-C files
- Parsing IERS Leap-second list files
- Fetching both the above files from the wibbly-wobbly-web
- Setting a predetermined frame rate (fps)
- Determining the refresh-rate of the monitor (Khz)
- Parsing a json file to preset options such as fps
- Fallback fps to refresh-rate of monitor
- Convert UNIX time (epoch: 1970-01-01 00:00:00) to one or more of:
- TAI (atomic time - epoch: 1900-01-01 00:00:00)
- TT (terrestrial time)
- UT1 (universal time)
- UTC (coordinated universal time)
- J2k (Julian 2000 epoch)
Each of the time frames mentioned above are useful, but I found library (a crate in Rust lingo) that handles time in TAI format and can be fed a UNIX time. It can then convert to other frames such as TT, and that actually means the business logic of converting UTC to AMT (Airey Mean Time is the time at the prime meridian on Mars) is vastly simplified.
Current Status
As I write this (12th Aug '24), I have resolved all of the issues described above, with the exception of cross-compilation which will have to be tested at a later date. I'm now at the stage where I can begin tackling the conversion of UNIX time to AMT.
Once the time is displaying AMT, it is simply a matter of adding or subtracting 4 minutes of time for each degree of longitude east or west of the prime meridian to determine local time.
I should stress that this project isn't to produce a finessed program, but to teach me more about Rust by tackling stuff that would otherwise take me a while to get around to. Having a goal in mind (an accurate clock) is important when you're in self-teaching mode.
In the image you can see a terminal window and (most of) the application window when running. For the application window, ignore everything below the Frame counter. The window displays the current time, the seconds of the current minute, and the frame counter which counts up to 250 and then cycles again.
On the terminal window you can see various output, including the path to the latest iers-bulletinC.txt, the number of leap seconds coerced from the bulletinC, the number of leap seconds derived from an iers list of the dates when leap seconds were added, and a calculated number of leap seconds by subtracting the time in UTC seconds from TAI seconds.
The calculated leap seconds can be seen by the display of seconds in Epoch TAI and Epoch UTC, so you can perform the calculation yourself.
This is followed by the informational line that says if we set the fps in the json file to zero, the fps will be set at the monitor refresh rate (assumption is the first monitor if there are several). It then outlays the number of milliseconds per frame, what the fps is and where the source for the fps is (if equal to the monitor refresh rate in Khz, it will be Monitor, otherwise it will be taken from the json file). Finally, the refresh rate of the monitor is expressed in Khz.
As you can see, the FPS is set to 10, because a clock really doesn't need to be faster than 10 updates per second for a clock with an atomic granularity of one second,, but any slower will allow the clock to visibly stagger from a clock with faster updates. That's lag folks! With the second counter just above the Frame counter, it is easy enough to see there are in fact 10 frames per second simply by watching the second counter and the tens part of the frame counter clicking over at the same time. It's an easy check to see the FPS is actually behaving as required.
At this point I've solved most of the really pressing issues, and can get on with performing the calculations needed to convert the time from the system clock to AMT.
Discussion