[linsomniac]

Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC.

When you run "date", it asks the system for this number of seconds, then uses a database to look up what that number corresponds to in the local timezone, accounting for leap years and seconds, and spits out that value. So when (some of us) recently "fell behind", the Unix time incremented by 1 second, but that database told us that the time had decreased by an hour.

Not exactly sure how Windows does it, but I recently set up monitoring of a job that Task Scheduler runs, starting at midnight and running for 1 day, every 5 minutes. I got paged at 11:30 because the scheduler decided "1 day" is "24 hours", and it stopped running it at 11pm because of the time change, but didn't start the one for the next day.

I know cron can be confusing, but I'll take it any day over this.

[zokier]

> Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC.

Wrong. UNIX time is number of days since epoch × 86400 + seconds since beginning of day.

In real world some days have been actually 86401 seconds long, which means that UNIX timestamp is (currently) 37 less than number of seconds since epoch.

[linsomniac]

Go ahead and correct it on Wikipedia, I double-checked my understanding against the entry there before posting my message, and re-reading it I think my description matched Wikipedia.

You'll also need to correct it in the time(2) man page, which says:

"number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)." (ubuntu 22.04)

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

[zokier]

The time(2) manpage also states

       POSIX.1 defines "seconds since the Epoch" using a formula that
       approximates the number of seconds between a specified time and
       the Epoch. [...] This value is not the same as the actual number of
       seconds between the time and the Epoch, because of leap seconds
       and because system clocks are not required to be synchronized to
       a standard reference [...] see POSIX.1-2008
       Rationale A.4.15 for further rationale

https://man7.org/linux/man-pages/man2/time.2.html#VERSIONS

The word approximates is carrying a lot of weight here. So basically "seconds since the epoch" is a posix codephrase which doesn't actually mean what you'd naively think it does. Why this useful info is buried in the VERSIONS section instead of the main DESCRIPTION I don't know.

For Wikipedia, there is already discussion about the confusing wording of the opening paragraph: https://en.wikipedia.org/wiki/Talk:Unix_time#Flat_out_wrong? but the body of the article is mostly better, and especially the table showing what happens during leap second should clarify matters.

[ThePowerOfFuet]

Then parent was correct but `s/UTC/TAI/g`; no counting of days nor multiplication required.

[SAI_Peregrinus]

Exactly. UNIX time, GPS time, and TAI are a fixed offset from one another. They're a variable offset from UT1 (based on earth's angle with respect to some distant quasars). If you care about things like where the stars are, use UT1. If you want monotonic time, use TAI or one of the time standards that's a fixed offset from it. If you want to plan a spacecraft trajectory through the solar system, use barycentric coordinate time (TCB). If you want something that approximates UT1 but otherwise works like TAI, use UTC.

If you're dealing with human activity, UTC will usually be the easiest choice. If you're just dealing with computers, TAI (or one of its fixed-offset variants like UNIX time) will usually be the easiest choice.

[zokier]

> UNIX time, GPS time, and TAI are a fixed offset from one another.

Wrong again. UNIX time definitely is not fixed offset from GPS time. Here is handy dandy conversion tool between the two: https://bag-of-tools.com/gps-time-converter/

1700000000 UNIX = 1384035218 GPS

700000000 UNIX = 384035207 GPS

[zokier]

That would be even more wrong. There has been some fringe suggestions to run UNIX clock on TAI, but that hasn't caught on (probably because it would be contrary to posix). So we are stuck with this mangled utc based monstrosity.