Considering time only moves forward, I would say computers aren't the only thing that would have issues with a second that moved backwards.

Time seems to simply be a way to keep track of matter in space, that is it seems to be a construct to explain the state of matter. Unless matter's state is being undone in space, I can't imagine how time would move backwards.

What?

I try to write software such that it would work for a time traveler (who takes the computer running the software with them) as much as possible. That is, distinguish between elapsed time within the system, which is monotonically increasing, vs. calendar time and time of day, which might go back and forth arbitrarily and is just a label. This isn’t always possible, for example with regard to external last-modified times, but designing with that distinction in mind tends to make systems more robust.

We have a monotonically increasing time, TAI (International Atomic Time). The problem is that people want 00:00 each day to correspond with midnight, and so we need either (a) varying seconds or (b) leap seconds. So we have UTC (Coordinated Universal Time) which uses leap seconds to stay within one second of UT1, which is the mean solar time at 0 degrees of longitude, and which has variable seconds.

Didn't we give up on having "the time" correspond to solar time in the 1800s with the advent of railways? Unless you live exactly upon a specific set of lines on Earth, 00:00 never corresponds to midnight, leap seconds or not.

Fair. It would be more accurate to say that people want the time of midnight and noon to be consistent across ~decades and centuries (and if the leap second isn't going to happen the leap minute or hour almost certainly won't...).

We already have a leap year, where we add an extra day every four years. So why could we not adjust the clock every 500 years when it gets out of sync by 20 minutes?

Yeah, I mean thats an option, but I basically expect that to cause a y2k-like level of emergency refactorizations as everyone realizes that their software isn't built for it.

On the other hand, we already have leap seconds. They're not much of a problem.

> On the other hand, we already have leap seconds.

Well, leap seconds are going away, so we don't.

They were never adequate for the long-term anyway, as the "two leap seconds a year" scheme will break down as the earth's rotation slows over the centuries and more and more leap seconds will be needed.

We're talking about an hour time drift over a few thousand years. Does that really matter? It's like caring what Julius Caesar's sense of "morning" or "evening" was. They never really solved any practical problem.

Human-readable time can be as simple as tagging monotonically increasing timestamps for the start of every day at the prime meridian. Calendars can count days and weeks and months as normal, but the exact timestamps won't exist for future dates until we observe them, which is fine. It's not a huge dataset to publish timestamps for the majority of historical times, or storing interpolations between months or entire years.

Approximations in calendar time can be used for the future where precision timekeeping is not needed (the holiday party next year at 8:00PM), and exact monotonic timestamps can be used where precision is needed (e.g. the timestamp to start a re-entry or orbital insertion burn around Mars).

Our calendars are already merely tags/counters for physical events (solstices, new moons, high noon) we observe, so making that distinction official in timekeeping standards makes sense to me.