OpenBSD adds support for Coordinated Mars Time
marc.info
marc.info
The scifi series Babylon 5 with its titular station used Earth Standard Time [1] while being placed in Epsilon Eridani system. That doesn't sound bad, I think.
The another issue the future colonists will have to deal with will be how to track days, months and years. There's Thomas Gangale's suggestion that does look interesting [2].
[1] - https://babylon5.fandom.com/wiki/Earth_Standard_Time [2] - http://ops-alaska.com/time/gangale_mst/darian.htm
Mars is the least useful planetary body in the Solar System for human colonization, so that time may well be "never".
The problem is that there is nothing useful on Mars and its location sucks. Any other planetary body makes more economic sense.
There’s nothing worth the shipping cost anywhere off the surface od the Earth, and all the rest of the planets are much worse locations than Mars. (Venus maybe slightly better if you are only getting to/from high atmosphere, but that has the “there’s nothing worthwhile there” problem more than Mars does.)
Or composition; its also not easier to reach (or return from) if you are going to the surface.
I suppose you could construct criteria and assumptions that would support that conclusion, but I can’t see a reasonable set where that works out.
Why? There's plenty of computers in Mars right now and they use martian time already [0]. It's not as if OpenBSD have invented anything new, they just adapted the OS to existing practices.
Now, if we'd be there already for decades or even centuries with permanent settlement then perhaps we'd have some date and time formats that would be similar to what we're having on Earth (or maybe they'd use the exotic decimal time) and I wouldn't be even writing the parent comment in first place.
Well, these people can use OpenBSD now ;)
Considering that the weather outside will kill you year-round on Mars, debate is of course rather academic...
That way I don't have to constantly be converting lunar timestamps, mars timestamps, etc. back to UTC (or the coordinated time of whichever celestial body I'm currently on) in order to paint a timeline of when events happened between my different devices spread out across the solar system.
I think I’m also saying that since time passes at different rates in different gravity scenarios, a single external reference may be the best way to coordinate time… even outside of our solar system.
While not a primary source, it's still an answer to absolute time from pulsars: https://physics.stackexchange.com/questions/175981/can-you-u...
Some exceptions to this exist due to orbital resonance: Pluto and Neptune are in 2:3 resonance, and in the Jovian system Ganymede, Europa, and Io are in 1:2:4 resonance.
Also simply travelling to Mars would desynchronize the time and would have to be resynced.
When working in an intertimezonal setting, however, that concept of a 24h day felt very weird. While the day and night cycle indeed is roughly 24h, the human productivity cycle appeared longer in duration as some people were having a normal morning work start at 1:00am on my clock and 8:00am their time.
This shifts the mental model to what it means for deliverables to be produced “today” or “on day X”. Is it their day or is it my day? It also shifts the perception of much work per day we are putting in, while on the paper it just is a simple per 24h division. Bob worked an 8h shift in a 24h workday which is in a 24h + 8h + 8h (arbitrary numbers chosen only for visualization) global workday, so did he now work enough? Did he work “all day”?
I came to the realization that a 24h long workday in such a setting feels arbitrary and off. It should be longer, but how long exactly.
This will only get worse once we have clocks running faster the further away we get from the gravitational field of the Sun or work on planets or moons with different day/night cycles.
How would one do it inside an Asteroid Mining Colony?
Also shipping atomic clocks to space is not all that outrageous idea. Few years ago NASA lauched Deep Space Atomic Clock[1], which is exactly what it sounds like. Also modern "chip scale" atomic clocks[2] are pretty small and low power, so I would not be surprised to see those in future missions.
[1] https://www.nasa.gov/mission_pages/tdm/clock/index.html
[2] https://www.microsemi.com/product-directory/embedded-clocks-...
B) If it’s not an AFJ then it sounds like an incredibly unnecessary set of potential bug creating code changes for a security focused operating system!
That said, there already are Linux machines operating on Mars and we can expect the number of computers working there to increase substantially within 10-20 years. That means that BSD and other OSes are going to have to implement some kind of Martian timekeeping anyway.
So perhaps it is better to start now, when the low-hanging bugs can be ironed out without accidentally bricking an important piece of machinery on another planet.
A truly universal time should probably be based on the orbits or other oscillations of atoms, possibly away from a gravity well and at a precise temperature.
...One of the first things you learn in special relativity is that there are no preferred reference frames, I still have trouble wrapping my head around that one.
A new "truly universal time" could end up, paradoxically, as a niche thing only used by hardcore enthusiasts, much like all the attempts to create an artificial universal language (volapuk, esperanto). Heck, we could not even get the whole world to adapt SI units of measurement.
I have not worked with cvs, so it's non trivial to figure out.
But if you want a browsable interface to OpenBSD’s repos (no CVS knowledge required), you can use either the project’s CVSweb [1] or the GitHub mirrors [2].