[russdill]

Yup, it seems awesome, but software needs to be written to handle it properly. I think it'd work no problem with software already written against monotonic clocks, but everything else would probably need some fixing.

[paulajohnson]

The problem is that time_t (seconds since 1970) implicitly assumes 86400 seconds per day. You would have to redefine time_t and rewrite every piece of code that uses it.

[kazinator]

Leap seconds is what allows that assumption to work.

Leap seconds exist only in real time, not in historic recorded time.

There are in fact 86400 "calendar seconds" in a day, exactly.

Essentially, when a day is done, we call it 84600, even though it's actually 86400.epsilon.

Only special applications need to know the exact physical number of seconds between two calendar times, rather than the calendar seconds.

[azinman2]

Right... Because leap seconds are high on everyone's priority list. It's the programmers fault!

Or... recognize that super rare bugs are inevitable and create a higher level way to avoid them entirely. I vote for option 2.

[kazinator]

That "new higher level way" is leap seconds. The concept of leap seconds allows us to do date and time calculations in "calendar seconds", and not care about the discrepancy between physical seconds and calendar seconds.

Leap seconds basically add a corrective jump to physical time (what is measured by our super accurate clocks that use physical seconds and not calendar seconds) to match calendar time.

Leap seconds matter if you're doing some scientific or engineering calculation (astronomy, aerospace or whatever) and you need an exact physical time down the fraction of a second between two events that are far apart in the calendar.

They do not enter into everyday calculations, like using time_t seconds to calculate the number of days between two dates.