←back to thread

How to Think About Time in Programming

(shanrauf.com)
189 points rmason | 3 comments | 24 Jun 25 20:01 UTC | HN request time: 0.728s | source
Show context
alphazard ◴[25 Jun 25 13:22 UTC] No.44377042[source]▶
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

replies(2): >>44377182 #>>44378566 #
1. theamk ◴[25 Jun 25 15:41 UTC] No.44378566[source]▶
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)

replies(1): >>44379337 #
2. alphazard ◴[25 Jun 25 16:46 UTC] No.44379337[source]▶
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.

replies(1): >>44380867 #
3. theamk ◴[25 Jun 25 19:10 UTC] No.44380867[source]▶
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.