Posted by gliffie 5 hours ago
The page lists several good reasons for this, including:
- It's a common source of bugs.
- Solar time is not that important in a world of coarse timezones.
- IoT and anything that cannot receive time updates have trouble with leap seconds.
- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
I'd also add:
- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to 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.
- Leap second unpredictability can make it impossible to calculate how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.
- The proper ISO8601 formatting of leap seconds ("23:59:60") is widely unsupported, breaking parsers, along with the assumption of how many seconds are in a minute, hour, or day.
---
EDIT: I've emailed hn@ycombinator.com to change the title. It's avoiding editorialization, but I think it's also preventing the post from getting the attention it deserves.
I'm booking a yearly one-second-long holiday on my calendar, to celebrate all the headaches this will save me. Happy end of leap seconds!
On a side note, I really like how the site formatted the reasoning. I'll be copying it to my technical writing.
FreeBSD tests stuff like this for the code that they take care of:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Third-party stuff (like from Ports) is another question.
From now on UTC will in practice be TAI but with a constant offset (=all previous leap seconds).
I don’t see that reason listed on the page, and future wall-clock times remain unpredictable due to changes in time zone rules.
What will become predictable is the relationship between posix time and elapsed time (in the sense of TAI), at least within the next few hundred years.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
This is unfair.
If AI wants to be a coder then it has to do leap seconds. In fact, let's give it leap minutes and leap hours too.
Edit...scratch that, now I have to keep track of UT1-UTC as a separately continuously varying parameter provided by IERS instead of tzdata
In the open seas, celestial navigation is more than accurate enough. Once you are closer to shore, where the greater precision is needed, better options exists. Lights, ranges, radar, visual, etc.
Which doesn't seem like that is soon, but time/calendar issues can creep up and then it's a big hullabaloo:
Sure, you could also run a relativistic simulation of the solar system, galaxy, and cosmos to establish a more monotonic clock and calendar independent of imperfect orbital parameters, but that's a bit much for discerning whether or not it's lunchtime.
Barycentric Coordinate Time: https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time
In the very far future, leap seconds would become inadequate anyway, as you’d have to insert them every month, then every week, then every day, due to the deceleration of Earth’s rotation.
Leap seconds never did me any harm but DST is a constant menace, adding complexity everywhere.
People have a hard time with leap years, which happen regularly every four years, so I'm curious to know how well a "one-off" event at a basically random time in the future will work.
