Every time I see ditching leap seconds come up, they never try to explain why TAI won't work for them, leading me to believe they probably just don't know it exists, nor could they even imagine something like it being invented.
Nanoseconds since X is a fairly unambiguous reference (relativity aside).
Use this for any kind of timestamp or recordkeeping. Convert to UTC (or EST, CST, etc.) as necessary for reference to the solar day.
The only reason not to do this is because you have a million systems that are already running on UTC, and you don't want to do a massive leap second erasure to get back to TAI.
From a software development perspective this seems monstrously more complex than just muddling along with the current situation even with leap seconds.
First, consider the question of "what do unix timestamps mean?" The answer is UTC, except just be broken during the second where there's an extra leap second added or removed, and don't try to represent it. They neither represent TAI nor UTC perfectly, and have no way to encode a leap second, but they are very space efficient to store needing only 8 bytes.
Now, we want to start converting our systems over to TAI, great! To do that we need a format to efficiently store a unix time in a binary representation. For this exercise let's use Jan 1, 1970, and so when we call it we get a value today that's equal to unix time plus 37 (the current offset between TAI & UTC). Awesome, now we need a new function to call it in every single language we use, and then migrate all callsites over to it. Try not to miss any places where someone's passing unix time as an int64 instead of, say, a time_t. If you call into libraries that return timestamps make sure you shim them so that you can convert those timestamps from UTC to TAI.
Now, we have the problem of how to store those int64s. We can't store them in place of our current timestamps, they'll be 37 seconds off. So let's add a field to all databases where timestamps are stored to store the TAI version. Additionally, every RPC is going to need to send along both TAI & UTC during the migration process, so change those too. We can't just ignore cases where we need an integer representation of time, either - those have historically been the places where systems break during leap second changes.
I hope this gets to a little bit of why it would be extremely non-trivial to use TAI in place of UTC right now. If you're storing your time as, say, a string representation with a time zone built in you're right, it's actually generally not that bad, and time zone information is frequently encoded in the string. It's _extremely_ difficult to deal with once you move to a representation of time where the timezone isn't directly encoded in a timestamp.
https://en.wikipedia.org/wiki/International_Organization_for...
The same reason that KFC (Kentucky Fried Chicken) is PFK in Québec... In French: Poulet Frit Kentucky.
Honestly, it feels more natural for adjectives to follow the noun. I think about this a lot when naming variables.
English is a quirky language.
>Oddly, languages either have the exact same ordering as English, or the exact opposite as English. And, nouns in various languages fall in some designated position between the string of adjectives -- in English it's at the end, in Romance languages it's somewhere in the middle, such that most adjectives follow the noun, but certain adjectives precede
The real answer is that deeply learning grammar as a child makes you think in grammatically correct ways to begin with, which means that when you start vocalizing a sentence, it's already queued up in grammatically correct form or very close to it. This is why we should teach children grammar grammar grammar and almost nothing but grammar, using poetry for memorization, reading to expose them to grammatically-correct texts, and writing to drive grammar home. And some 'rithmetic.
mostly everything.
I am a native speaker, which means that I didn't realise that british english isn't actively taught. Like we aren't taught grammar in any particular way (apart from I before E, except after C, which is mostly bollocks, because it depends on the origin of the word. [their for example.])
Basically we are dipped in the language and we either succeed, or in my case dumped in remediation. (I can't spell for shit)
I didn't realise this until I was learning another language as an adult. They were usings terms like "present continuous, reflexives, compound verbs, etc" None of which I knew the practical meaning of.
Teaching a child to read, again you just realise that basically its 5 different languages smeared together, with shit all rules. Syntax, yeah we have some, but no native speak can explain the rules. (we have adjective ordering , but I don't know what it is, I can only tell you if you've got it wrong.)
Missing second half of the rhyme: "or when sounded like 'a' as in 'neighbor' or 'weigh'"
I doubt anyone talking about the elimination of the leapsecond is unaware of TAI but TAI is not readily available on general purpose computers (and, increasingly, UTC is being silently substituted for leap-smeared UTC). And for specialized systems attempts to make pockets of TAI break down when they have to talk to the outside world (and have consistent times with it) and/or due to hardcoded leapsecond tables in software.