FreeBSD Support for Leap Seconds

Take this as your reminder to participate in lobbying against leap seconds. They serve no useful purpose: The drift between civil noon and solar time they prevent would take thousands of years to reach even 1 hour. The thing leap seconds are tracking "mean solar time" is not something that exists, it's a mathematical abstraction; actual solar time differs substantially from mean solar time depending on your location and the time of year. Applications that care about solar time are usually frustrated by leapseconds in any case; since they result in unpredictable discontinuities in the difference between solar time and civil time; and most systems provide no way to report the history of leap seconds to applications.

If people still care about solar noon matching civil noon 4000 years from now they simply need shift the timezones by an hour. This is a much safer and more reasonable change which could be planned a hundred years in advance and wouldnt require a constant feed of unpredictable "trusted" leap seconds. Systems already handle mixed timezones well and will continue to do so since computers exist worldwide.

As more distributed systems become sensitive to second-scale timing and the cost of reliable oscillators that can keep time autonomously continues to decline the cost of leap-seconds will continue to increase; but the value they provide (primarily political bragging rights about Greenwich being part of the definition of civil time) will remain at practically zero for almost everyone.

Workarounds like leap-smear are just that-- workarounds, and add more possible failure modes to leap-second handling and will cause different failure modes for applications that care about time in different ways, e.g. caring about frequency vs time; or just from having even more ways to handle the leap second.

Moreover, the discontinuation of leapseconds is simple and nearly costless. Announce that no more will be issued; then don't issue anymore of them.

In my opinion leap seconds shouldn't exist in software. Time should be continuous from some point of time (1970-01-01 works fine) and leap seconds should only account when software performs formatting (or parsing) of date-time.

I like that they clearly describe how FreeBSD handles leap seconds, but when I read the headline I was hoping they were announcing support for leap smearing.

I'm just imagining the subtle bugs that can happen if the developer can't assume a minute is 60 seconds and that each minute is the same length.

This seems like a feature for no one, as the people who really care about leap seconds are probably doing their own timekeeping already since computer clocks aren't exactly accurate to being with.

Could someone explain to me why the leap seconds can't simply be inserted on the leap day in February? Never mind, that just makes way too much sense I assume :) Just like not having daylight savings time, or 30 min offset time zones, or months with either 31 or 30 days, mostly arrange in a random order.

My ideal time system would have 13 months, with 12 30 days months plus 1 end of the year month with either 5 or 6 days (plus an occasional leap second). An no damn daylight savings time. Of course, it would make a lot of sense to put the beginning of the year at the beginning of the first month of spring, not the _second_ month of winter. But again, nothing about modern calendar makes much sense. You begin to realize how insane it is only when you are forced to write a time library from scratch in C++ as part of a C++ course. I did that in high school, and it was really eye opening.

Why is repeating the :59 second better than adding a :60 second?

I have never understood why leap seconds are not phased in over a specific time period rather the current method of adding the entire adjustment at once.