> People, myself included, like to say that POSIX time, also known as Unix time, is the number of seconds since the Unix epoch, which was 1970-01-01 at 00:00:00.
> This is not true. Or rather, it isn’t true in the sense most people think.
I find that assertion odd, because it works exactly as I did assume. Though, to be fair, I'm not thinking in the scientific notion that the author may.
If we think of a second as a tick of some amount of time, it makes sense to just count up once each tick. That scientists inject a second here or there wouldn't interfere with such logic.
All of that said, the leap second is going away anyways, so hopefully whatever replaces it is less troublesome.
The article is needlessly unclear, but the specification given in the second blockquote is the one that is actually applied, and a simpler way of explaining it is: POSIX time() returns 86400 * [the number of UTC midnights since 1970-01-01T00:00:00] + [the number of seconds since the last UTC midnight].
POSIX doesn’t ignore leap seconds. Occasionally systems repeat a second, so time doesn’t drift beyond a second from when leap seconds were invented: https://en.wikipedia.org/wiki/Leap_second
The leap second in Unix time is supposed to wait a second and pretend it never happened. I can see why a longer second could be trouble, but also… if you knew it was coming you could make every nanosecond last 2 and lessen the impact as time would always be monotonic?
> This is not true. Or rather, it isn’t true in the sense most people think.
I find that assertion odd, because it works exactly as I did assume. Though, to be fair, I'm not thinking in the scientific notion that the author may.
If we think of a second as a tick of some amount of time, it makes sense to just count up once each tick. That scientists inject a second here or there wouldn't interfere with such logic.
All of that said, the leap second is going away anyways, so hopefully whatever replaces it is less troublesome.