SD cards have a limited lifespan, and the more you write to them, the closer they edge to the end of that life. With this in mind, I wanted the clock to write to the SD card as little as possible, even though the amount it would write would be fairly trivial. This should also speed up the clock at certain bottleneck situations, especially boot-up.

First up, I needed to determine when the clock wrote to the card, then I needed to create a strategy to limit the number of times it would need to do so. First up was the missions file.

The missions file is not large (currently less than 8k) but to determine the version would require downloading the entire file, which may or may not be a slow process, and if the downloaded file is the same as the currently stored file, a waste of time and energy. I opted to place a version file, which is just a small text file of just 22 bytes, beside the missions file. Downloading this is quick and easy and it loads straight into a memory variable which can then be compared against the currently held version.

Only if there is a new version does the program fetch the new missions data file and write it to the SD card. Since this file is expected to remain unchanged for large amounts of time, this is an optimal method of checking and updating.

Leap seconds are added at set times of the year. The preference is at the end of June and the end of December, but may also be added at the end of March or September. Incidentally, they're not actually added - they're subtracted from Universal Time - but since they accumulate, we tend to think of them adding.

The program doesn't know when it was last booted up, so duing the initialisation process it will read a notification (a bulletin C) an determine the number of Leap Seconds from it. Of course, it may be months out of date, but it has enough information to allow the clock to continue bootong up and display the clock.

However, before it releases the clock to do that, it checks to see if a new bulletin has been released. New bulletins are issued every six months, but mainly they say that no leap seconds will be added 'in the next six months'. It fetches the latest bulletin and if no leap seconds have been added it discard it. Therefore, the copy on the SD card may be several years out of date, but nothing has changed since it was issued.

If a new leap second has been added, it updates the configuration file and the internal memory structure that represents it, then saves the new bulltin to the SD card, overwriting the old copy. Now that the new value has been saved to the internal memory structure, the clock will update using the new value on the next tick.

Once running, the clock will check once per day whether it is the 1st of January, April, July or October (the days when a new leap second might come into force) and checks to see if a new leap second has been added. In other words, it'll check once on startup, then 4 times a year thereafter.

The configuration file is updated every time a new leap second is detected, when a new missions data file is downloaded, and whenever the user selects [ Save & Exit ] from the configuration screen. Other than that, it is only read.

This file contains the list of interesting coordinate presets that are not directly related to missions, and also includes any ad-hoc coordinates added by the user to the presets. Since this can be added to and deleted from, it is updated whenever the user chooses one of those options. The user can edit the presets as much as they like, but if they choose the [ Abort ] function, their edits are discarded. They are only written to the Coordinates file if they choose [ Save & Exit ].