For systems that leap seconds actually cause problems on, the solution is simply to use International Atomic Time (TAI) internally, and convert it to UTC when you want to display information to a user.
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.
Seriously, I was reading this article wondering the same thing.
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.
> ... the solution is simply to use International Atomic Time (TAI) internally, and convert it to UTC when you want to display information to a user.
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.
Coordinated Universal Time in French is Temps Universel Coordonee (give or take an accent). So that should be TUC. I don't think there's any language in which UTC stands for anything. It's a fake acronym.
The problem with English is that you have to plan out the whole noun phrase in your head before you start talking. Not only do the adjectives have to come first, they have to be in the right order. With Romance languages you can just say the noun and then keep tacking on adjectives as they occur to you.
>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
Well yeah, the adjective order is actually mostly semantic, and tracks something similar to intensivity. Varying adjective order is not normally a grammatical error per se, it's emphatic (though emphasizing the wrong thing is a pragmatic error).
But in Romance languages you have to plan out very complex sentences. I mean, you don't have to, but it's what people do.
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.
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.)
That one's even odder - that's the compromise between the English version, which would be CUT and the French version which would be TUC ... i.e. none of the above.
TUC is a brand of crackers well-known in France, so maybe that’s why they didn’t insist on the French version. And CUT obviously didn’t make the cut. ;)
There are very few systems that care about second-level time that leapseconds don't cause issues for. They are almost universally mishandled by widespread systems, so much so that we even get multi-million dollar scale internet disruptions due to leapseconds when there hasn't even been a leapsecond.
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.
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.