[haberman]

What is the actual benefit of this?

The cost is that conversion to/from civil time is far more complicated, and worse, cannot be computed for future dates for which leap seconds have not yet been determined.

I think that 86,400-second days with a 24-hour leap smear hits a sweet spot of utility and usability: https://developers.google.com/time/smear

There are very few applications that will know or care that seconds get 0.001% longer for 24 hours.

[wongarsu]

Skipping or smearing leap seconds means conversion to/from civil time is simple ... as long as you only want an accuracy of +-1 second.

If you need better conversion, you have to know how the system chose to handle leap seconds. If it smears, you have to know and implement the smear algorithm, if it doesn't then some unix timestamps will map to two different points in civil time (second 59 and 60 in any hour with a leap second).

For 99.9% of applications, it's not a bad tradeoff. But if we're willing to fudge time by up to a second, recording time in TAI (just count a second every second) and living with future dates sometimes being off by a couple seconds when converted to UTC isn't that different in terms of utility/usability tradeoff, and conceptually simpler.

[marcosdumay]

If you need better precision, you don't go converting to/from civil time, because people think on quanta of ~1 second and better precision is not defined there.

Instead, I'll put my rule here: It's perfectly reasonable to drop your time precision to ~1 second when converting it into "people time", and you should never expect better precision from a back conversion.

That's not saying you don't need TAI. It's just not reasonable to mix it and UTC et. al. If you need TAI, you live in TAI.

[hinkley]

How many times a second do computers communicate notions of time between each other, versus to a human? We’re talking many orders of magnitude here, and inequalities like that always change the winning strategy.