Context: BIPM is responsible for the UTC time standard, and in this document they decide to stop adding (or removing) leap seconds, starting on 20th of May 2027 and lasting for the foreseeable future (until one leap <i>hour</i> is needed). Together with the decision to not add a leap second in December, the 27 leap seconds that have been added so far should be the only ones.<p>The page lists several good reasons for this, including:<p>- It's a common source of bugs.<p>- IoT, embedded systems, and anything that cannot receive time updates have trouble with leap seconds.<p>- Leap seconds make predicting the clock time of timestamps in the future impossible. You'll still need a hardcoded list of the previous 27 leap seconds to get the clock time of past timestamps.<p>- <i>Negative</i> leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.<p>- Not mentioned in the page, but Unix timestamps are actually defined as "seconds since epoch <i>minus however many leap seconds have happened</i>". It's a hack to make the keep code that assumes 86400 seconds in a day from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.<p>@dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation.