Important: Make GPS/UTC/TAI/TT conversions leap-second aware

[zoglauer]

Currently, MReadOutAssembly performs time conversion using fixed offsets for UTC/TAI/TT/GPS conversions, e.g. GPS - UTC = 18 s, TAI - UTC = 37 s, and TT - TAI = 32.184 s. These are correct for the current leap-second state, but the UTC-related offsets can change when IERS announces a new leap second - next one could happen 1/1/2027.

This a category of bug, which doesn't show up now, but will knowingly and definitely show up some time in the future.

Suggestion:

• Add a nuclearizer-wide time conversion helper for GPS <-> UTC <-> TAI <-> TT (e.g. MTimeConversions) and remove them from MReadOutAssembly

• Avoid hard-coding leap-second offsets in individual classes.

• Track leap seconds via either:
  - a small local leap-second table, or
  - a standard library such as ERFA, or
  - NAIF CSPICE if we want a broader mission/space-science time system.

• Keep TT - TAI = 32.184 s as a named constant.

• Make the currently valid TAI - UTC / GPS - UTC offset date-aware.

• Add unit tests around known leap-second boundaries.

[mwy-wing]

I agree with refactoring it. From my perspective, I prefer to maintain a small local leap-second table in Nuclearizer.

• ERFA does not provide native GPS time conversions, so we would still need to implement the GPS ↔ TAI offset ourselves while relying on ERFA for UTC ↔ TAI conversions. It feels like we would be using two different approaches to solve one problem when we could keep everything in one place.
• CSPICE requires loading a leap-second kernel before doing the time conversions. We would also be adding the entire CSPICE library as a dependency when all we currently need is leap-second handling. I am not sure whether we will need other capabilities from CSPICE in the future, but for now I feel like there is little difference between having CSPICE parse the leap-seconds.tls file and parsing it directly in Nuclearizer. If we decide to use the file-based approach, parsing it ourselves would avoid introducing another dependency.

Happy to hear what you think.

[ckierans]

I also agree with bringing the time conversions out into a MTimeConversions class.

Having a small table for the offsets makes sense to me.

I was under the impression that the leap seconds were not going to change any time soon, but avoiding the hard-coded conversion is best practice so let's do that.