Every string-formatting function must have a new prefix of "m" for Mars-safety: msprintf, mstrftime, etc. An extra int argument must be included to indicate whether to format in Martian or Earth sols. Clearly the addition of this new argument will 100% future-proof the API against any other modifications required as humanity expands into space.

Wouldn't it be better to just add an argument for which celestial body the calculation is being performed for? This would be more flexible in the future.

I guess this would work well for other bodies as well, like moons.

...if you look up fast enough, you might just see the tail end of the joke as it passes over your head.

Talking to yourself, there?

Frequently, but it's a bit harder than that. Days on different planets don't have 24 hour durations. Try and adapt that to every date library ever.

I work on display libraries for multiple projects including MSL, and the standard solution is to use "slow seconds" and force Mars days to be 24 hours.

I did ask moment.js how they might support Mars time and didn't get far.

https://github.com/moment/moment/issues/2391

Interesting question. Even NASA can't standardize.

Each lander mission so far has used its own time zone, corresponding to average local solar time at the landing location. Of the six successful Mars landers to date, five employed offsets from local mean solar time (LMST) for the lander site while the sixth (Mars Pathfinder) used local true solar time (LTST).

https://en.wikipedia.org/wiki/Timekeeping_on_Mars#Time_zones

That's pretty straightforward, actually --- just fail, setting errno EABSOLUTETIMEISAMEANINGLESSCONCEPTINGENERALRELATIVITY.

There was a reason why modern C extended the identifier limit, you know.

Actually absolute time SINCE an epoch (event and frame of reference) is meaningful. You can convert between times in different epochs. E.G. if we consider the epoch of a particular event on mars (Curiosity snapped a photo) we could convert that from the IAU_MARS frame of reference into the J2000 reference frame and find the seconds since a significant event, e.g. the TDB reference when the prime meridian first pointed directly at the solar system barycenter in the year 2000.

So those time conversions need to be augmented to understand reference frames in the special case, or continuous reference transitions in the general case. I am sure it will be a gnu extension by 2020.