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

Local time isn’t just a view it gets down into the model. You can’t effectively model “every Tuesday at 4pm until cancelled” as a series of timestamps because it comes with an implied “…regardless of changes to daylight saving rules.”

Heck you can’t even model “Oct 15 2030 at 2pm” as a timestamp for the same reason if it is an appointment involving two humans in the same tz.

Somewhere you need to store the rule using local time concepts.

The input to the scheduler would be “every Tuesday at 4pm", and that would produce a schedule out to some time horizon. The schedule would be in terms of timestamps. When the criteria changes, the scheduler is rerun and a new tentative schedule is produced.

> Somewhere you need to store the rule using local time concepts.

The scheduling rules can be in terms of whatever you want and maybe that's local time or a timezone or soonest free block, but they are being used to solve for timestamps in the actual schedule. You run into problems if the scheduler output is in terms of any of those concepts.

My favorite mistake is when people assume it is only daylight savings time that you need to consider. I could just be on vacation in a different place, but still want to keep the same schedule. And indeed, knowing that most places open around 9ish local time everywhere is very convenient.

Another fun aspect of this topic is how people will tacitly jump around the definition of "day" being when the sun is up without confronting that that is, itself, not a given. And, worse, is completely thrown out if you try to abolish time zones.

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)

Agreed, but amazingly high number of people (ab)use the local time notation for things which don't need it, like timestamps of various events (login time, order time, etc..)

It's worth repeating over and over: "Only use local time if the actual moment event happens depends on the timezone, like during future calendar entries. Every other time in the system should be a utc timestamp, converted to local time string at the very last presentation layer"

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.

The "most common intuition" is that if you have a timestamp X, and you add 3600 seconds, you get a same time but in next hour (unless there are timezone shenanigans). But that's not true for TAI - it's entirely possible that 3600 seconds after 23:30:00, the time is 00:29:59. No intuition works like that.

So that's why I always advocate for UTC, ideally with smeared leap seconds (although this point is kinda moot now). The 0.00000001% of people who actually care about leap seconds can use the library to get TAI.