Actually the progression will be 1230767999, 1230768000, 1230768000, 1230768001. POSIX Unix time is UTC with the explicit exception that it doesn't handle leap seconds, so there is a discontinuity when leap seconds occur. The leap second is the first of the two 1230768000 numbers.

One would hope that the struct tm that you get from localtime() or gmtime() will have tm_sec=60 at the leap second, but given an ambiguous time_t as its argument, I'm not sure how that would be possible. So I assume that it never actually hits 60.

right/ assumes that the system's idea of time_t is pseudo-TAI with the 1/1/1970 unix epoch remaining the same (as opposed to TAI which is defined as UTC+10s in 1972) On systems support it you get the full leap-second treatment (tm_sec==60, etc) Difficulties:

Your system's idea of time_t will now be 23 (going on 24) seconds off from the rest of the world. Have fun synchronizing. I'd imagine there's some ntpd-guru trick to do this but I don't know what it is.

Are you sure there's no code you run that assumes tm_sec is 0..59?

Will every remote machine that you exchange formatted dates with deal with 23:59:60? (for example, if you're running a web server will clients cope with that in the "Date:" or "Last-Modified:" header?)

Are you sure there's no regex's anywhere on your system that include ":[0-5]\d" or similar when parsing dates?

The lack of an actual 60th second is cool for us lazy programmers, though. Just divide by 86400 to count the days without accounting for any weird fractions from leap seconds. Which I'd been blithely doing for years without thinking about it until our prototyping wizard started asking deep questions about Unix time during development of the Epoch Clock. Anyway, thank you, Epoch Time Gods.

I was under the impression that the Earth rotated without any assistance from giant steam engines buried beneath the Earth's crust and maintained by a shadowy organisation separate from any merely human government.