Space
-
Day 28: What an Interplanetary Civilization Needs From a Clock
A couple of weeks ago, on Day 12, I took the tour. A Mars day is 39 minutes too long. The Moon’s clocks run about 58 microseconds a day fast. A round trip to Voyager takes two days. Astronomers already juggle a whole family of relativistic coordinate timescales to keep it all straight. If you want the details, it’s there.
Today I want to ask the question that tour sets up but doesn’t answer. Given all of that, what would a clock for an interplanetary civilization actually have to be? Not the problems. The design.
And this isn’t a thought experiment. Right now, at NASA, ESA, and the White House Office of Science and Technology Policy, people are building the first piece of it, with a 2026 deadline. The design question has a clock running on it, which makes it worth getting right.
Why we can’t just ship Earth time
The instinct is to take what works here and copy it outward. It doesn’t survive the trip.
What we call “time” on Earth is two different things welded together. There’s a coordinate layer, the uniform atomic tick underneath UTC, and there’s a display layer: the time zones, the calendar, daylight saving, the assumption that 12:00 means the sun is roughly overhead. We never separate them because we never had to. Everyone who matters lives on one planet, rotating once a day, so the weld holds.
Leave the Earth’s surface and it breaks down. The Moon’s day is four Earth weeks long, so “noon” is useless as a unit of human activity. Mars’s day is close to ours but drifts a full cycle out of phase every forty days. A clock deeper or shallower in a gravity well ticks at a measurably different rate. The display layer assumes things that are only true on Earth. The coordinate layer is the only part that travels.
How you’d actually design it
Here are my principles that I’ve come up with on designing a time system for interplanetary civilization. Call them pillars. None of them care which body you happen to be standing on.
1. A coordination layer underneath everything. One shared timescale that every machine, log, and database syncs to. This is the part we already do well: TAI and the timescales built on it are a solved problem. The coordination layer is non-negotiable, because without a single shared reference nothing else holds together.
2. Uniform ticks, and precision matters. The tick has to be uniform, repeatable, and stable, with an error bar low enough that the rate doesn’t measurably change over thousands, ideally hundreds of thousands, of years. The cesium second clears that bar today. It won’t be the last word: optical lattice clocks are already orders of magnitude more precise, and the definition of the second may eventually move to them. How you reach the precision can evolve, by averaging more clocks or adopting better physics. The principle doesn’t. Uniform ticks, and the smaller the error bar the better.
3. A civil layer shaped around people, not physics. On top of the count, each body gets a civil layer for the humans living on or near it: a local “day” from whatever its rotation gives, a calendar, zones, whatever fits. There is no universal right answer here, and that is the point. The civil layer is supposed to be local and negotiable. Getting it right is also the whole game for adoption, because people don’t adopt a coordinate count. They adopt the layer they read off the wall. Calendars are a good example. Everything we dug into on Day 23 and Day 24 lives entirely at the civil layer. The coordination layer doesn’t care about calendars, it just counts. We can change the calendar without changing how we measure time.
4. Store it as integers, not strings. Underneath, time should be a single growing integer, a count of ticks from a fixed origin. Unix time got this right: one number, trivially comparable, trivially sortable, no parsing. The moment you store time as a string like “2026-06-14T10:00,” you have handed every machine a parsing-and-timezone problem it never needed. Strings are for display. The truth is an integer.
5. Pick the zero point deliberately. Every count needs an origin, and the choice is more loaded than it looks. We touched on it on Day 10. Unix picked midnight 1970. Others anchor to a calendar epoch, a mission start, a physical event. There’s a real argument that an interplanetary zero point shouldn’t be tied to any one planet’s history at all. It’s a deeper question than it first appears, and I want to come back to it before the series ends.
6. Plan for the rollover before you ship. An integer that only grows eventually runs out of bits. That’s not hypothetical: it’s the 2038 problem sitting in every 32-bit
time_t. A time system meant to outlive its designers has to use a counter wide enough that it won’t overflow on any timescale anyone will live through, plus a clear migration path for when the assumptions break anyway. Thinking ahead is part of the design, not a patch you bolt on later.7. Relativity is not optional, so plan for the gravity well. There is no single universal tick rate. There is no now, and there is no master clock either. How fast a clock runs depends on how deep it sits in a gravity well and how fast it’s moving, so two clocks on two different bodies will never agree on raw elapsed time. The coordination layer doesn’t erase that. It manages it. Every location keeps its own proper time and converts to the shared reference through a known relativistic offset. GPS already does this at 38 microseconds a day; the Moon will do it at 58. The shared timescale isn’t a clock anyone physically holds. It’s a convention everyone translates into and out of, and the deeper the gravity well, the larger the correction.
Putting the pillars together, we get the shape of a system. The core of the idea is this: make it easy for humans, precise for machines.
We’re already building it
That architecture, one clean coordinate timescale plus a thin local display layer, is exactly what the metrologists have been inching Earth toward for years. It’s what abolishing the leap second is for. It’s what “civil time is a coordinate, not a description of the sky” actually means. It’s the thing every reformer in yesterday’s post was reaching for and couldn’t get adopted.
And it’s not hypothetical. Coordinated Lunar Time is being built as exactly this: an atomic timescale, relativistic corrections applied at the surface, mathematically traceable back to UTC, with a thin local display on top. The coordinate machinery already exists. The civil layer is the only genuinely new part, and it’s deliberately thin.
We’ve spent the whole series watching Earth refuse to make that separation, because the current arrangement is old and familiar and changing it has no immediate individual payoff. Going off-world doesn’t introduce a new problem. It removes the excuse. You cannot run a Moon base on leap-second-corrected, sun-anchored, time-zone-laden Earth time. The system breaks the instant you leave the surface, and we are about to leave the surface, in numbers, on a timeline shorter than most people realize.
The clock an interplanetary civilization needs is the clock we should probably already be using. The off-Earth deadline is just the thing that finally forces our hand.
Tomorrow I want to pull all of this together. Twenty-eight days of small, separate-looking problems: leap seconds, time zones, calendars, DST, relativity, leaving Earth. Tomorrow, the shape of all of them at once.
Sources
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
Day 12: Earth to Mars, Come In
NASA’s Mars mission control runs on Mars time, not Earth time.
For the first few months of every landed mission (Curiosity, Perseverance, Insight), the scientists shift their work schedules by 39 minutes every day.
They go to sleep 39 minutes later, wake up 39 minutes later, do all their meetings 39 minutes later than yesterday.
After a few weeks they’re working at 3 AM Earth time. After a month they’re working at noon. After two months they’re back to where they started.
This is what living on Mars time looks like to humans. It is exhausting and demonstrably bad for sleep. They do it anyway because the rovers don’t care about Earth’s schedule.
Let’s talk about why time on Mars is hard.
The sol
A Martian solar day is called a sol, and it’s about 24 hours, 39 minutes, 35 seconds.
That’s almost an Earth day. Close enough that NASA’s first instinct in the 1970s was to use Earth time for Mars missions anyway.
Bad idea. Within a single Martian month, your Earth-time schedule drifts nearly a full day out of phase with the local Martian one.
The rover’s morning camera shots happen during your meeting. Its solar panels charge while you’re trying to sleep.
So NASA started using Mars time for the human side of mission ops. They built Mars-time wristwatches in the 1990s, actual mechanical watches modified to run 2.7% slower, and gave them to mission controllers.
They built Mars-time-aware mission scheduling software. They renamed “day” to “sol” so nobody got confused.
It worked. It was also brutal on the humans, because human circadian rhythms evolved for Earth’s 24-hour day, not Mars’s 24-hour-39-minute one.
Mars time shifts your sleep 39 minutes later every day, which is roughly equivalent to flying west across two time zones, every day, forever.
After a few months I can see everyone getting their schedules wrecked.
Each rover has its own time zone
Mars doesn’t have just one time. Each rover gets its own time zone, called Local Mean Solar Time (LMST), based on its specific longitude on Mars.
Curiosity is in Gale Crater. Perseverance is in Jezero Crater. They are about 3,700 kilometers apart on Mars, and they keep local solar times that differ by about four hours.
Curiosity is roughly four hours later in its day than Perseverance, because Gale Crater is 60 degrees east of Jezero.
If you’re a rover and you want to know when the sun will rise tomorrow, you use your LMST, not the other rover’s.
There’s also a coordinated reference: Coordinated Mars Time (MTC), anchored to Airy Crater, which is roughly the Mars equivalent of Greenwich.
Airy is where Mars’s prime meridian sits by IAU convention, and MTC is the mean solar time at that location. Most planetary scientists default to MTC when reporting Mars events without specifying a longitude.
So Mars has its own day (the sol), its own time zones (LMST per location), its own Greenwich (Airy Crater), and its own UTC-analog (MTC).
The whole planet has built up a parallel set of timekeeping conventions, derived from the same basic problem Earth solved: a rotating body needs a way to talk about when things happen.
The Moon is being figured out right now
In 2024, the White House Office of Science and Technology Policy directed NASA to establish Coordinated Lunar Time (LTC) by 2026.
The Artemis program needs it. So does every commercial lunar lander launching this decade: SpaceX, Blue Origin, ispace, Astrobotic.
All of them need to coordinate communications, navigation, and surface operations on the Moon, and they need a shared time standard to do it.
The Moon’s timekeeping problem is harder than Mars’s, for two reasons.
First, the Moon’s day is 29.5 Earth days long (synodic). A lunar “noon” lasts 14 Earth days, and so does the night.
The whole concept of “day” as a unit of human activity falls apart. Lunar mission ops will likely use Earth-anchored time for everything and ignore the local sun.
Second, relativity matters more than you’d think. Clocks on the Moon run about 58 microseconds per day faster than clocks on Earth’s surface, due to the Moon’s weaker gravity well.
That’s bigger than GPS’s 38 µs/day. If you want a lunar communication network to synchronize with Earth-side networks, you have to bake in the correction the same way GPS did, but more aggressively.
LTC is being designed right now. The current proposal is an atomic timescale traceable back to TAI, with relativistic corrections applied at the lunar surface.
It will probably be ready before Artemis 3 lands humans?
Deep space and the light-delay problem
Beyond the Moon and Mars, time becomes a different problem entirely: light delay.
- Round-trip to Mars: 6 to 44 minutes, depending on orbital geometry
- Round-trip to Jupiter or Saturn: hours
- Round-trip to Voyager 1, currently 24 billion kilometers from Earth: about 46 hours
You can’t run NTP to a spacecraft beyond the Moon. The sync protocol assumes round trips of milliseconds, and the universe doesn’t oblige.
The Deep Space Network (NASA’s array of giant antennas at Goldstone, Madrid, and Canberra) sends time-tagged commands to spacecraft, and spacecraft tag their telemetry with their own onboard atomic clocks.
The clocks have to be reliable for years or decades without correction, because by the time a round trip resolves, you’ve moved on to the next problem.
For interplanetary work, physicists use three relativistic coordinate timescales:
- TCB (Barycentric Coordinate Time): a clock that lives at the center of mass of the solar system. The natural frame for tracking planets, asteroids, comets.
- TCG (Geocentric Coordinate Time): a clock at Earth’s center. The frame for tracking Earth satellites and orbital mechanics close to Earth.
- TT (Terrestrial Time): a clock on Earth’s geoid. What UTC is derived from. What humans live in.
TCG drifts about 22 milliseconds per year from TT. TCB drifts nearly half a second per year from both.
Most humans never encounter this.
Anyone doing calculating planetary calculations does.
The deeper point
“The day” is parochial. It works only on the body where it’s defined.
Earth time scales fine on Earth. GPS scales fine in Earth orbit. Mars time scales fine on Mars. None of them scale to each other.
Every body in the solar system has its own “now,” and there’s no single instant that applies everywhere at once.
It’s a consequence of relativity. Time literally runs at different rates at different gravitational potentials and different velocities.
A clock at the solar system barycenter ticks differently than a clock on Earth. There is no “true” rate. There are only frames.
So how do we coordinate? The standard answer, for spacecraft and astronomers, is to pick a coordinate frame, anchor everything to it, and convert as needed at the destination. TCB for solar-system work. UTC for Earth civilians. GPS for navigation. LTC (coming) for the Moon. MTC for Mars.
The clocks themselves are “easy” but the coordination between them is the not.
The civilian question, what time is it if I want to call my friend on Mars, has no clean answer.
You pick a coordinate frame, you both agree to use it, and you live with the conversion. There’s no “Mars time on your phone” because there’s no Mars infrastructure to sync your phone with.
And even if there were, you’d still have to handle the light delay.
Tomorrow we come back to Earth, and to the most ubiquitous time format in human history: the number of seconds since midnight, January 1, 1970.
Sources
- Timekeeping on Mars — Wikipedia
- Coordinated Lunar Time — Wikipedia
- Barycentric Coordinate Time — Wikipedia
- Geocentric Coordinate Time — Wikipedia
- Terrestrial Time — Wikipedia
- Curiosity rover — Wikipedia
- Perseverance rover — Wikipedia
- InSight — Wikipedia
- NASA Deep Space Network — Wikipedia
- Voyager 1 — Wikipedia
- Clockmaker Helps Mars Rover Keep Mars Time — NPR
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
Using Claude to Think Through a Space Elevator
When I say I wanted to understand the engineering problems behind building a space elevator, I mean I really wanted to dig in. Not just read about it. I wanted to work through the challenges, piece by piece, with actual math backing things up.
So I decided to see what Claude and I could do with this kind of problem.
Setting it Up
I have an Obsidian vault that Claude Code/CoWork has access to, and I started by asking it to help me understand the core challenges of building a space elevator. First things first: clearly state all the problems. What are the engineering hurdles? What makes this so hard?
From there, I started asking questions. Could we use an asteroid as the anchor point and manufacture the cable in space? How would we spool enough cable to reach all the way down to Earth? Would it make more sense to build up from the ground, down from orbit, or meet somewhere in the middle?
I’ll admit I made some mistakes along the way. I confused low Earth orbit with geostationary orbit at one point but Claude corrected me and explained the difference. That’s part of what makes this approach work. You’re not just passively reading; you’re actively thinking through problems and getting corrected when your mental model is off.
Backing It Up With Math
Here’s where it got really interesting. I told Claude: don’t just describe the problems. Prove them. Back up every challenge with actual math and physics calculations.
I also told it not to try cramming everything into one massive document. Write an overview document first, then create supporting documents for each problem so we could work through them individually.
So Claude started writing Python code to validate all the calculations. I hadn’t planned on that initially, but once it started writing code, I jumped in with my typical guidance. Use a package manager, write tests for all the code.
What we ended up with is a Python module covering about 12 of the hardest engineering challenges for a space elevator. There’s a script that calls into the module, runs all the math, and spits out the results. It’s not a complete formal proof of anything, but it’s a structured way to think through problems where the code can actually catch mistakes in the reasoning.
And it did catch mistakes. That’s the whole point of this approach, you’re using the calculations as a check on the thinking, not just trusting the narrative.
Working Through Problems Together
As we worked through each challenge, I kept asking clarifying questions. What about this edge case? How would we handle that constraint?
It was genuinely collaborative, me bringing curiosity and some engineering intuition, Claude bringing the ability to quickly formalize ideas into code and calculations.
The code isn’t public or anything. But the approach is what I think is worth sharing.
The Hard Part Is Still Hard
My main limiting factor is time. The math looks generally fine to me, but if I really wanted to verify everything thoroughly, I’d need to spend a lot more time with it. A mathematician or physicist who’s deeply familiar with these calculations would be much faster at spotting issues. Providing guidance like, “no, you shouldn’t use this formula here, that approach is wrong.”
I can do that work. It’s just going to take me significantly longer than someone with that specialized background.
This is what I mean when I talk about working with agentic tools on hard problems. It’s not about asking an AI for the answer. It’s about using it as a thinking partner; one that can write code, run calculations, and help you check your reasoning as you go.
For me, that’s the real power of tools like Claude. Not replacing expertise, but amplifying curiosity.
-
The World's Strongest Cable Is One Atom Thick
I fell down a rabbit hole this morning. It started with a simple question: how far are we really from a space elevator? This really is a feasibility question, and I"m convinced that the answer is probably no, but for a really fascinating reason.
The Basic Problem
A space elevator needs a cable stretching from Earth’s surface to geostationary orbit, so about 36,000 kilometers up. That cable has to hold its own weight, plus whatever cargo you’re lifting, plus deal with a counterweight extending beyond geostationary orbit that’s constantly trying to pull away to balance everything out.
The heavier the cable, the more stress it puts on itself. So you need something impossibly light and impossibly strong. Carbon nanotubes were the go-to candidate for years, but even their theoretical limits fall short of what’s needed. The forces involved are just too extreme.
Enter Graphene
Graphene is similar to carbon nanotubes, but instead of a tube, it’s a flat hexagonal lattice of carbon atoms… so essentially a really long sheet, or aka a ribbon.
The world’s strongest cable isn’t round. It’s flat, and it’s one atom thick.
That’s kind crazy to think about, that the strongest material we can come up with is literally as thin as matter gets.
Why It Still Won’t Work (Probably)
Even if graphene has the right properties on paper, we have a number of impossibly hard engineering problems.
Manufacturing: We can’t produce a continuous ribbon of graphene anywhere close to the lengths needed. We’re talking thousands of kilometers of perfectly formed, single-atom-thick material. So not happening.
You don’t want one ribbon anyway: Even if you could manufacture a single ribbon that long, you wouldn’t want to. You need redundancy. If one section gets damaged — and at 36,000 km of exposure to space debris, micrometeorites, and atmospheric forces, damage is a when, not an if. You need backup ribbons to bear the load. So you’d need separate sections, separate lengths.
The bonding problem: And this is where I think the whole concept falls apart. There’s no reliable way to bond or clamp separate graphene ribbons together. Think about it… how do you reliably verify that something one atom thick is actually bonded properly? Every single joint, every repair, becomes a critical failure point. You can’t just slap a section in place and hope for the best.
To do that in a reproducible, verifiable way, at scale, in space, repeatedly. I think that’s the thing that makes the space elevator functionally impossible. Not conceptually impossible, but practically impossible.
The Climber Problems
I’m deliberately ignoring all the problems the climber introduces (the mechanism that actually lifts cargo up the cable). There’s a whole separate set of headaches there. But the cable itself is the fundamental challenge, and it comes down to this:
We might have identified the right material. Graphene’s properties are genuinely remarkable. But knowing what to build something out of and knowing how to build it are two very different things.