Re: [RFC] Timekeeping for other planets

["Joshua Peisach" <jpeisach@ubuntu.com>]

On Tue May 26, 2026 at 4:14 PM EDT, John Stultz wrote:
> On Tue, May 26, 2026 at 6:59 AM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>>
>> For a while I've thought about timekeeping on other planets. If humans
>> ever make it to other planets, there will likely be other systems for
>> keeping track of time, because the length of a day is not the same
>> across all planets. Mars, for example, has a longer day than Earth.
>> There are some proposed systems for timekeeping on Mars, the most
>> interesting one being the Darian calendar system[1], but there are
>> things like "Mars Sol Date" and Coordinated Mars Time (MTC).
>>
>> So my internal, curious and enthusiastic personality lead me to try
>> making a C library that would try to handle time and date conversions
>> for other planets. But it actually gets quite difficult and confusing,
>> because (to save you the time and story) there ends up being "so what is
>> an Earth second and what is a Mars second"?
>>
>> Now that I've made some kernel contributions (I still consider myself a
>> newbie), I think about how there may actually be good reasons for trying
>> to handle non-Earth times in the kernel, compared to the silly people
>> like me having their timekeeping systems in userspace. For example,
>> things like log timestamps. A machine that is running Linux on another
>> planet (I know, it's ambitious, but humor me), will report events in
>> terms of seconds. But, that's in terms of Earth seconds. For humans, it
>> would make sense to use a time system that applies to Mars for its own
>> calendars. So if someone is reading the logs and they see "one million
>> seconds", how would they know exactly when the message occurred? One
>> million Earth seconds does not equate to one million Mars seconds.
>>
>> (I try not to think about the "how long is a second" thing..)
>>
>> My point is, if humans adopt timekeeping systems for other planets,
>> there may (or may not?) be a good reason for the kernel to keep track
>> of time outside of Earth.
>>
>> Now, I am being ambitious, very optimistic, and potentially delusional
>> for thinking that people would want to use other timekeeping systems in
>> other planets, and still have Linux be around in the far future, and
>> choose to have timekeeping in the kernel instead of in userspace. But,
>> I know I'm not the only person interested in this topic. There is NASA's
>> Mars24 Sunclock[2] which does track time in terms of hours, minutes and
>> seconds, but at the rate that it does on Mars.
>>
>> So, the problem: There is currently no way to handle or provide
>> timekeeping on other planets, aside from conversions. But maybe that
>> should only stay in userspace. The users affected: well, as of writing,
>> astronomers and space enthusiasts, looking to track events and time
>> using other planetary timekeeping systems and calendars.
>>
>> I admittedly don't know much about timekeeping in the kernel, but there
>> are functions for atomic time, which could actually get some use!
>
> Appreciate your interest!  When adding functionality to the kernel, we
> do have to ask what is the benefit gained from moving logic into the
> kernel if it could otherwise be done from userland.  Logic we add to
> the kernel that has uABI visibility requires indefinite maintenance,
> potentially introduces bugs, etc. So there has to be a clear benefit
> to do so.
>

I understand. Maybe I could try to do some benchmarking to determine if
the time it takes to query the time is sufficient.

> For the most part, timezone handling is already dealt with in
> userland, so it seems like using CLOCK_TAI + similar userland handling
> would be the a reasonable approach to what you want without having to
> add more complexity to the kernel.
>
> thanks
> -john

This isn't just timezones (though there are timezones on Mars), the
entire calendar system would have changed, and hence things like the
length of a second would as well.

I actually watched Stephen's presentation earlier today about
timekeeping in the kernel. If there was to be some "implementation",
maybe it would have to be with changing that multiplier in the mult
then shift function - but as you said, without a "clear benefit", no
use at the moment.

-Josh