←back to thread

How to Think About Time in Programming

(shanrauf.com)
189 points rmason | 2 comments | 24 Jun 25 20:01 UTC | HN request time: 2.96s | source
Show context
zokier ◴[24 Jun 25 22:11 UTC] No.44371602[source]▶
It is a pet peeve of mine, but any statement that implies that Unix time is a count of seconds since epoch is annoyingly misleading and perpetuates such misconception. Imho better mental model for Unix time is that has two parts, days since epoch * 86400, and seconds since midnight, which get added together.
replies(2): >>44371952 #>>44374623 #
valenterry ◴[25 Jun 25 07:42 UTC] No.44374623[source]▶
But it's correct. It's "a" count. Just not the count that you might always expect. And the "second" in this definition means what people usually understand as a second, as in the duration is always the same. That's all, and it's pretty useful imho.
replies(1): >>44374796 #
zokier ◴[25 Jun 25 08:10 UTC] No.44374796[source]▶
> And the "second" in this definition means what people usually understand as a second, as in the duration is always the same.

Umm what? In Unix time some values span two seconds, which is the crux of the problem. In UTC every second is a proper nice SI second. In Unix time the value increments every one or two SI seconds.

replies(1): >>44375569 #
valenterry ◴[25 Jun 25 10:17 UTC] No.44375569[source]▶
Really? Now I'm confused
replies(1): >>44377441 #
1. zokier ◴[25 Jun 25 14:00 UTC] No.44377441[source]▶
The table in Wikipedia is good for clarifying matters:

https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

From there you can clearly see that e.g. Unix time 915148800 lasted two seconds

We can make an analogy to leap days:

- UTC is like Gregorian calendar, on leap years it goes Feb28-Feb29-Mar1 (23:59:59-23:59:60-00:00:00)

- TAI would be just always going from Feb28-Mar1 (23:59:59-00:00:00) and ignoring leap years

- Unix time would be like to go Feb28-Mar1-Mar1 (23:59:59-00:00:00-00:00:00) on leap years, repeating the date

From this it should be pretty obvious why I consider Unix time so bonkers.

replies(1): >>44383989 #
2. valenterry ◴[26 Jun 25 03:39 UTC] No.44383989[source]▶
Indeed, it's the opposite of what I thought. Confusing! Thanks for the clarification.

So in fact, unix seconds can be longer than intuitively expected. Which also means two timestamps of e.g. UTC with different seconds can map to the same unix timestamps.