How to Think About Time in Programming

There's nothing special about time. These sorts of problems show up whenever there are a few overloaded terms being used to model a larger amount of concepts.

Confusion about special and general relativity accounts for almost none of the problems that programmers encounter in practice. If that's your use case, then fine, time is special and tricky.

The most common issue is a failure to separate models vs. view concepts. e.g. timestamps are a model, but local time, day of the week, leap seconds are all view concepts. The second most common issue is thinking that UTC is suitable to use as a model, instead of the much more reasonable TAI64. After that it's probably the difference between scheduling requests vs. logging what happened. "The meeting is scheduled next Wednesday at 9am local time" vs. "the meeting happened in this time span". One is a fact about the past, and the other is just scheduling criteria. It could also be something complicated like "every other Wednesday", or every "Wednesday on an even number day of the month". Or "we can work on this task once these 2 machines are available", "this process will run in 2 time slots from now", etc.

https://cr.yp.to/libtai/tai64.html

You've had me agreeing until TAI64 reference... Why would you optimize your software for super-rare case (super high precision time intervals) at the expense of making a very common case (timestamp -> calendar time) harder? Unless you are into computerized astronomy or rare physics experiments, there is never a need to worry about leap seconds or TAI. For long intervals, having 1-second error every few years to reduce code conversion complexity is totally worth it.

(note that for the short intervals, when a single second actually matters, you should use neither TAI nor UTC, use monotonic timer provided by your OS)

The TAI64 extensions N and NA for nanoseconds and attoseconds repspsectively are for the super rare cases you're talking about, but that's not the reason to use TAI64, which by default has second resolution. The main reason is that it preserves the most common intuitions about time (that it goes in a single direction at a constant rate). Distance between two TAI64 timestamps is the number of seconds elapsed. Future will never be equal or less than the past.

This shouldn't affect code complexity at all. None of this logic belongs in the application code. You take your timestamp stored as state and convert it to a presentation format by calling a library in both cases. Converting timezones yourself by adding or subtracting hours is asking for trouble.