The second is broken

The following table includes quotes and links to articles from contexts where the current definition of the second is broken. This issue is causing confusion and unnecessary expense, as individuals and corporations are forced to navigate through this broken system.

JULY 25, 2022	It’s time to leave the leap second in the past "While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead." "At Meta, we’re supporting an industry effort to stop future introductions of leap seconds and . . . we believe it is time to introduce new technologies to replace it." "At best, such a time jump crashed programs or even corrupted data, due to weird timestamps in the data storage." "The impact of a negative leap second has never been tested on a large scale; it could have a devastating effect on the software relying on timers or schedulers." "In any case, every leap second is a major source of pain for people who manage hardware infrastructures."
October 27, 2018	Where are the leap seconds in javascript? (1 answer) "The fact is, that the unpredictable nature of leap seconds makes them very difficult to work with in APIs. One can't generally pass timestamps around that need leap seconds tables to be interpreted correctly, and expect that one system will interpret them the same as another." "To be clear - to support leap seconds in a programming language, the implementation must go out of its way to do so, and must make tradeoffs that are not always acceptable. Though there are exceptions, the general position is to not support them - not because of any subversion or active countermeasures, but because supporting them properly is much, much harder."
November 28, 2012	What time scale is used by the jpl horizons system? "I'm confused by the use of the term "UT" in the description of time scales used by the JPL HORIZONS system." "My understanding is that UTC has leap seconds, so that there should be an extra second at the end of a day on which a leap second was added, but the intervals reported by HORIZONS lacks these, and look more like UT1" "Even more confusingly, the data reported do in fact behave as if the times are UTC. For example the reported azimuth of Pluto at Greenwich for the times above changes by 0.0028° for each of the intervals but the third, where it changes by 0.0069°, a factor of 2.5 times the change in each of the other intervals, which is exactly what would be expected ((1 + 2/3)/(2/3)) if there were an extra second between 2012-Jun-30 23:59:59.333 and 2012-Jul-01 00:00:00.000. This, despite the fact that the difference in JD over that interval is the same as each of the other intervals, meaning that one can't expect differences between JD that span any leap seconds to line up with changes in data!" "If the times and data are UTC, how can the differences between JD be uniform? If they're UT1 how can the data "jump" at the leap second?"