Seconds Since Time

It’s not all news, but it comes up often enough that I think there should be a brief explanation of the problem. People, including myself, like to say that POSIX time, also known as Unix time, is number on seconds FROM THE Unix TIMESwhich is 1970-01-01 at 00:00:00.

This is not true. Or rather, it is not true in the sense that many think. For example, it is now 2024-12-25 at 18:54:53 UTC. The POSIX time is 1735152686. This is 1735152715 seconds since POSIX time. The POSIX time number is twenty-nine seconds less.

This is because the POSIX time is derived of IEEE 1003.1 from Coordinated Universal Time. The standard assumes that each day is exactly 86,400 seconds long. Specifically:

the time() function returns the value of the time of seconds since the Epoch.

Which is defined as:

seconds since the Epoch. A value to be interpreted as the number of seconds between a specified time and the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), time (tm_hour), days since January 1 of the year (tm_day), and calendar year minus 1900 (tm_year)) is associated with a time represented as seconds since the Epoch according to the expression below.

If the year is <1970 or the value is negative, the relationship is indeterminate. If year ≥ 1970 and the value is non-negative, the value is associated with a Coordinated Universal Time name according to the expression:

tm_sec + tm_min * 60+ tm_hour * 3600 + tm_day * 86400 + (tm_year-70) * 31536000 + ((tm_year – 69) / 4) * 86400

The length of the day is not 86,400 seconds, and actually changes over time. To keep UTC days from drifting too far from solar days, astronomers periodically declare a jump second in UTC. Because of this, every few years the POSIX time jumps backwards, Preying SPEAK DISPUTE. Someday it may leap forward.

Appendix B of IEEE 1003 has an interesting discussion of leap seconds:

The concept of leap seconds was added for accuracy; at the time this standard was published, 14 leap seconds had been added since January 1, 1970. These 14 seconds were ignored to provide an easy and compatible way of computing time differences.

I also like to take things for granted to make my life easy. Common writers know that “seconds since time” are not, in fact, seconds since time. And they admit as much:

Most systems of the idea of ​​”time” is a continuously increasing value, so this value should increase even during leap seconds. However, not only do most systems not track leap seconds, but most systems are likely not synchronized to any standard time reference. Therefore, it is not appropriate to require that a time be represented as seconds because the Epoch precisely represents the number of seconds between the referenced time and the Epoch.

It is sufficient to require that applications be allowed to treat this period as if it represented the number of seconds between the referenced time and the Epoch. It is the responsibility of the system vendor, and the system administrator, to ensure that this value represents the number of seconds between the referenced time and the Epoch as close as necessary for the application running on that system….

I imagine there is a debate on this point. The appendix punts, saying that vendors and administrators should make the time alignment “as close as necessary”, and that “this value should increase even in leap seconds”. The latter is achievable, but the former may be impossible: the standard requires POSIX clocks of twenty-nine seconds.

Consistent interpretation of seconds since Epoch can be critical in some types of distributed applications that rely on such timestamps to synchronize events. The accrual of leap seconds in a time standard is unpredictable. The number of leap seconds since the Epoch will probably increase. The standard is more concerned about time synchronization between applications in the short astronomical period and the Working Group expects that these concerns will become more critical in the future.

In a sense, the opposite happened. Time synchronization EVER off, so systems usually work (albeit incorrectly) when times drift slightly. But leap seconds are so rare, and the linearity evoked by the phrase “seconds since time” is so deeply baked into our intuition, that software can accumulate serious, undetected bugs. Until a few years later, one of those tiny little leap seconds wiped out a huge chunk of the internet.

If you need to calculate the time between two events on a computer, use CLOCK_MONOTONIC. If you don’t need to exchange timestamps on other systems with POSIX time, use TAI, GPS, or maybe LORAN. If you need bad alignment with other POSIX-timestamp systems, smear leap seconds in a longer time window. Libraries like it’s qntm can convert back and forth between POSIX and TAI.

There is an ongoing effort to ending in leap secondsI hope so in 2035. It takes more work to create conversion tables to everything that relies on the “86,400 seconds per day” assumption, but it should also make it easier to ask questions like “how many seconds are between these two moments”. At least for the times after 2035!