Return to Answer

POSIX rejects (a) for simplicity of calculations, but otherwise matches UTC to match civil time, hence rejecting (c) and choosing to accept downside (b). Simplicity of calculations is explicitly mentioned in the rationale:

POSIX rejects (a) for simplicity of date calculations, but otherwise matches UTC to match civil time, hence rejecting (c) and choosing to accept downside (b). Simplicity of calculations is explicitly mentioned in the rationale:

(The sentence "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." is weird in itself, given UTC is "the actual time of day" for pretty much all practical purposes, and the definition above relies on UTC. I'm not sure what that refers to, but it might just mean to say that the system clock is not required to be accurate. And well, without external synchronization, most computer clocks aren't.

Similarly, "Broken-down POSIX time is therefore not necessarily UTC, despite its appearance." in the rationale part looks odd, but would apply at the moment of a leap second. Otherwise the given equivalence seems to be ok.)

• A brief introduction to the Falsehoods programmers believe about Unix time by Alex Chan.

• The SE post Unix time and leap seconds contains some discussion and links to a convincing-sounding post "The Unix leap second mess" by David Madore.

• That one mentions dealing with this in NTP, and on that, there's Five different ways to handle leap seconds with NTP in Red Hat Developer(s) Blog.

• One of those approaches is of course what Google started using with their "leap smearing" in 2008. (Obligatory XKCD)

• And the Wikipedia page on Unix time has a table similar to the above, showing the repeating value, while also including TAI along with UTC.

Also, this is one of those cases where a simple but exact solution just doesn't exist. You get to pick any two good things out of three and have to put up with either

• a) days of variable length (in seconds);
• b) seconds that themselves vary in length; or
• c) a date system that ends up getting out of synch with the Sun.

POSIX rejects (a) for simplicity of calculations, but otherwise matches UTC to match civil time, hence rejecting (c) and choosing to accept downside (b). Simplicity of calculations is explicitly mentioned in the rationale:

The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length-as measured in seconds since the Epoch-for all days. Thus, leap seconds are not applied to seconds since the Epoch.)

(The sentence "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." is weird in itself, given UTC is "the actual time of day" for pretty much all practical purposes, and the definition above relies on UTC. I'm not sure what that refers to, but I think it just means to say that the system clock is not required to be accurate. And well, without external synchronization, most computer clocks aren't.

Similarly, "Broken-down POSIX time is therefore not necessarily UTC, despite its appearance." in the rationale part looks odd, but would apply at the moment of a leap second. Otherwise the given equivalence seems to mean broken-down POSIX time is UTC.)

• A brief introduction to the Falsehoods programmers believe about Unix time by Alex Chan.

• The SE post Unix time and leap seconds contains some discussion and links to a convincing-sounding post "The Unix leap second mess" by David Madore.

• That one mentions dealing with this in NTP, and on that, there's Five different ways to handle leap seconds with NTP in Red Hat Developer(s) Blog.

• One of those approaches is of course what Google started using with their "leap smearing" in 2008. That is, exchanging a single double-length second for a larger number of just-slightly-off seconds. (Obligatory XKCD)

• And the Wikipedia page on Unix time has a table similar to the above, showing the repeating value, while also including TAI along with UTC.

• That one second is two (physical, SI / UTC) seconds long, so clearly they're not all the same length.

• The epoch "moving" is what follows if you take the "all days are 86400 seconds" definition, assume constant-length SI seconds and work back on that. (That is, since UTC 1972-07-01 00:00:00 is 78796800 SI seconds after UTC 1970-00-01 00:00:01, that must be the effective epoch at that time.)

• As above, that one second is two (physical, SI / UTC) seconds long, so clearly they're not all the same length.

• The epoch "moving" is what follows if you take the "all days are 86400 seconds" definition, assume constant-length SI seconds and work back on that. (That is, since UTC 1972-07-01 00:00:00 is 78796800 SI seconds after UTC 1970-00-01 00:00:01, that must be the effective epoch at that time.)