"The unix time stamp is merely the number of seconds between a particular date and the Unix Epoch." - unixtimestamp.com
Unix Timestamp ≠ "seconds since epoch":
Inspired by "Falsehoods programmers believe about time", this post aims to demonstrate why the Unix timestamp is not equal to the "amount of seconds sind the epoch".
What is the Unix Timestamp?
It's the number of days since 1.1.1970 00:00 multiplied with 86400 (plus the seconds of the current day, if we're talking about the current timestamp at this moment). Each day is treated as 86400 seconds, which is the simplification that leads to the false assumption above.
Or, as Wikipedia puts it:
"Unix time is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix epoch, minus leap seconds."
This is currently true, but not necessarily if other changes to the real length of a day happen. Theoretically there could be shorter or longer days for any reason, and unix time would still account for those days with 86400 seconds.
Over the course of the years, the earth turns faster or slower, and our "normal" leap day/year system (which would be already complicated enough) doesn't account for this, and we get an offset of the day/night cycle compared to our timing system.
So every now and then, a leap second is added, to account for such variations. Leap seconds are announced to be inserted (or removed) on June 30 or December 31 of a year. You can read about it in great detail on the Wikipedia page.
A current list (valid until June 2021) of leap seconds:
Current lists can be found here:
- IETF: https://www.ietf.org/timezones/data/leap-seconds.list
- IERS: https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat
The calculation on top of this post is updated automatically if another leap second is introduced.
Leap seconds since 1970... or 1972?
But why only 27 seconds, not 37? At 1972, the difference between UTC and TAI was defined to be 10 seconds exactly, which brings us to the total amount of 27 introduced leap seconds since.
Between 1970 and 1972, UTC was still quite a bit of a mess, and variable-length seconds were used; Only from 1972 "regular", atomic TAI seconds which we use today are used. This makes the whole thing a bit more complicated, as we're taking 01.01.1972 UTC as anchor point and then go back using regular-length seconds, ignoring how UTC was really back then.
An excellent summary can be found here, "Old-UTC, new-UTC":
"This is why, to avoid ambiguity, Unix time can be said to be the number of TAI seconds elapsed since UTC 1972-01-01 00:00:00, plus the amount of TAI seconds in two TAI years, minus the amount of leap seconds since 1972. But most just say it's the number of seconds since UTC 1970-01-01 00:00:00, implicitly referring to the retrofitted UTC time-stamp, implicitly using TAI seconds, and generally forgetting to add the "minus leap seconds" part."
A detailed (and very technical) write-up which I recommend is "The Unix leap second mess", if you're interested in digging deeper.
So I shouldn't use unix timestamps?
That's not the point of this post - I don't have anything against using unix timestamps - they're often a convenient way of storing timestamps, and also offer enough for most practical purposes.
It's just important to keep the implications of the definition in mind:
- The unix timestamp is not the number of seconds since Jan 1, 1970 - sure, it's somewhat close, but still wrong to state so.
- A timestamp is not a unique point in time - You might not always be able to "map" a unix timestamp to an instant in time - sometimes, there are to instants in time which have the same unix timestamp. For example, 1483142400 refers to both 23:59:60 on Dec 31, 2016 and also to 00:00:00 Jan 1 2017.
- Not every unix timestamp is guaranteed to have a point in time - while this currently is the case, if a negative leap second is introduced, there will be a gap and a certain unix time will have no corresponding instant in "real" time.
- The offset isn't fixed - It's currently at +27 (since 01.01.1970), but will likely change over the years like it did until now.
- The offset is not guaranteed to always become bigger - theoretically, also negative leap seconds could be "inserted" (removed). This hasn't happened until now though (since 1971).
Thanks for reading!