[marcosdumay]

Unix systems usually do not have extra seconds after 23:59:59. Leap seconds are normally dealt with by slowing your clock down. So Unixes use neither UTC or TAI, they use something else.

It's something that does not matter in 99.99% of the cases, and that other 00.01% need specialized hardware and software for dealing with it anyway.

[wahern]

More specifically, POSIX explicitly defines a day as having precisely 86400 seconds. This makes calendar arithmetic trivial, including into the future, which would otherwise be impossible as leap seconds aren't predictable. Any program with a leap day bug is almost certainly not making use of Unix timestamps.

The corollary is that for the most commonly used APIs a Unix second isn't the same thing as an SI second. A Unix second is effectively defined in terms of the civil calendar, not as a fixed quantum of physical time.

Technically this doesn't preclude Unix date-time strings from displaying a 60th second. (And maybe some do.) But it would require unnecessary extra work, introduce inconsistencies (i.e. a generated string for a future date-time that happened to be a leap second would show :59 today but :60 at the moment of the leap second), and invite bugs.

[klingonopera]

Precisely, get yourself five digital devices that track time, and see how many of them are even accurate to the second. Probably none of them. But implementation of leap seconds would only make sense on systems that at least fulfill that minimum criteria.

Leap seconds are things for stock market servers, atom clocks, scientific devices and the like.