What time is it?

I hate timestamps. I'm fairly sure every developer does.

Time zones alone are enough. Most are whole hours from UTC, but some are 30 minutes off, and Nepal is 45 minutes off. Some of the borders follow politics rather than geography. Every project I've worked on has ended up with its own pile of custom date logic, and every pile has had bugs in it.

Then there are the units. Why are there 24 hours in a day? Why 60 minutes in an hour, and 60 seconds in a minute? We measure almost everything else in tens, and then we get to time and suddenly we're doing arithmetic in base 60 and base 24 at once.

"What time is it?" should be the simplest question there is. The answer shouldn't depend on where you're standing or which rules your government decided to follow. It shouldn't jump an hour twice a year because of a policy that dates back more than a century. And it shouldn't need leap seconds, which exist only to keep a patched-together system lined up with a planet whose spin wobbles.

The analysis that got it backwards

When I worked at Charter, I was asked to find out whether expiring DHCP leases were knocking customers offline. A DHCP lease is how a modem gets its IP address. If the lease runs out and isn't renewed, the device can drop off the network, so it was a reasonable suspect.

At first the data seemed to agree. Leases expired, and then the downtime started, which looked like a pretty clear answer.

It wasn't. The two datasets I was joining had been built independently by teams in two different time zones, and each team had recorded times in its own local time. Nothing in the data said so, and nothing in the documentation did either.

Then Spark made it worse. Spark is the system we used for all of our ETL (pulling data out of systems, reshaping it and loading it somewhere else) and the rest of our data engineering: it splits big data jobs across many machines and runs the pieces in parallel. Internally, Spark's timestamp type stores an exact instant, which is fine. But it tries to be helpful: whenever it shows you a timestamp, or turns one into text, it converts it to the session time zone, which by default is the local time zone of the machine running the job. It doesn't add the time zone to the text, and it doesn't warn you.

That's great if all you want is to look at the data. It breaks things when you need everything to be standard. Any string operation on a timestamp, like formatting it, pulling out the date or the hour, or casting it to text to write it out, works on that local-time version. The shifted value then gets saved as if it were the original. A lot of timestamps that were supposed to be UTC had been quietly moved to Mountain or Eastern time, depending on where the job ran, before they were ever written out.

Once I'd untangled all of that, the order flipped. Devices went offline first, and their leases expired because they were offline. The leases weren't the cause at all; they were a symptom. Same data, opposite conclusion, and the only thing that changed was knowing what time each row was actually recorded in.

Yes, UTC exists, and it would have prevented this. But people have to choose to use it, and most people never think about time zones until one of them has already caused a problem.

The cat sitter

More recently, we went to Japan and arranged for someone to watch our cats. I booked the flights in the United app, which helpfully added them to my Google Calendar. The calendar showed us leaving Japan on the 20th and landing in Denver on the 21st, so that's what we told the cat sitter.

We landed on the 20th. Because of the date line, we touched down in Denver earlier in the day, by the local clock, than we had taken off from Japan. We got home a day before our cat sitter expected us.

As problems go, that's the good version. The cats were fed, and the sitter got a day off. The other direction, where the sitter thinks you're back a day before you are, ends with hungry cats and a day nobody accounted for. But it bothered me that neither United nor Google, two companies with enormous engineering teams whose products exist largely to tell people when things happen, could get this right. If they can't, the rest of us don't stand much of a chance.

I spent a good part of that flight trying to answer a question that sounds simple: what time is it on the plane? Japan time? Denver time? Whatever zone you happen to be flying over? Every answer requires picking a reference point and converting everything else to it, and that's exactly the kind of mental bookkeeping that leads to mistakes like the one in my calendar.

Daylight saving

Then there's daylight saving time. Colorado passed a law to stop switching clocks. We still switch. It turns out the law only takes effect if Congress allows it and several other states in our time zone pass the same law. So twice a year we all move our clocks, lose or gain an hour of sleep, and break a few scheduled jobs, for a change our own state legislature has already voted to drop.

Why is it like this?

Beyond Earth

If people end up living on the Moon or Mars, what time is it there? What time is it on the ship halfway between? Does Mars get time zones? Does the ship observe daylight saving?

I went looking for how scientists handle this. Astronomers do have time scales for it, including Barycentric Coordinate Time (TCB), which is kept at the solar system's center of mass instead of on Earth. But even TCB starts from Earth. It's anchored to the start of 1 January 1977, as measured by atomic clocks on Earth: a date from the Gregorian calendar, which is a 16th-century papal reform of a Roman calendar, which counts years from the traditional birth of Jesus. In practice, getting to TCB also means converting from Earth time, and starting from UTC still goes through the leap-second table.

TCB is a real improvement, but it still has a reference point that some people on one planet agreed on. I wanted something free of any politically or culturally defined reference.

So I built one

Out of a mix of frustration and curiosity, I built the tx clock. The idea is that "what time is it?" has the same answer everywhere in the solar system.

tx clocktx-clock.vercel.app Open the clock ↗

One tx is one SI second of TCB. It's the same length as the second your phone counts, but measured in a frame that doesn't belong to any planet. The count starts at tx 0, the moment Saturn and Neptune lined up as seen from the solar system's center of mass, on 11 December 2025. That's a physical event, not a date anyone picked, so it doesn't belong to any country, religion or calendar. Anyone with a planetary ephemeris can recompute that moment, and it's frozen to a whole tx so that better measurements can never move it.

There are no time zones, no leap seconds and no calendar. Longer spans use metric prefixes instead of hours and days: a ktx is about 17 minutes, an Mtx about 11.6 days, and a Gtx about 32 years.

That doesn't mean giving up days or calendars. You still sleep at night and plant in spring. tx is the timestamp you store; local days and calendars become a way of displaying it. That's already how well-built software handles time: store one universal number, then show it however the reader needs.

What the clock does

• Live count. The page shows the current tx since zero, grouped as Mtx, ktx and tx.
• Converter. Converts between ordinary dates and tx, from 1972 to 2100.
• Other worlds. Switches between Earth, the Moon and Mars, and shows how fast a clock there runs against tx, plus the light delay from Earth. Earth clocks, it turns out, lose about half a tx a year.
• Scale. Shows how long familiar things take, measured in tx.
• Solar system. A 3D simulation of 51 bodies around the solar system's center of mass, showing how fast a clock on each one runs.
• The physics. The core is written in Rust and runs in the browser as WebAssembly. It works out TCB by integrating the solar system's relativistic equations of motion, with no fitted series or lookup tables, and agrees with the international reference to within about 30 billionths of a tx through 2050. The desktop version doesn't trust your computer's clock at all; it checks the time against five national time labs.

What's next

I haven't used tx for anything real yet. Once I've settled the last few details, I plan to start storing timestamps in my own projects as tx, and I'll write about how that goes.

In the meantime, you can try the clock at tx-clock.vercel.app. If you have a timestamp horror story of your own, I'd like to hear it.