[leni536]

Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.

[Unklejoe]

At least the IEEE 1588-2008 (PTPv2) protocol uses TAI time (with the POSIX epoch). The current UTC offset is then passed in the Announce messages (as well as some flags for indicating an upcoming leapsecond) which allows the slave to derive UTC if it wants to.

[nothrabannosir]

Because leap seconds are not deterministic, kind of like time zone changes. It would make timestamp <--> date calculations A) harder and B) need constant updates to work. Hell for firmware and embedded code.

Edit: the worst thing is: it would make those calculations harder to do correctly, but it would be too seductive to not care for leap seconds. After all, what's a few seconds error, really? This leaves you in a state where, guaranteed, 99% of time software will not be correct and the error will compound over time.

[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.

[detaro]

Google introduced this exactly to not have to deal with it client-side, while still having UTC timestamps that match the rest of the world most of the time.

[leni536]

You have to deal with it at client side. It doesn't make sense to fix broken software by introducing broken time servers. It could make sense to provide a wrapper library that provides smeared leap seconds and use that for broken software only (like libfaketime).

Now if I want to write software that uses precise TAI, I can't do that because of broken UTC from time servers and TAI is defined as UTC+tai_offset on my side.

[nullc]

> Now if I want to write software that uses precise TAI, I can't do that because of broken UTC from time servers and TAI is defined as UTC+tai_offset on my side.

Yup. Even if your NTP UTP source is perfect (lol), there aren't any cryptographically authenticated sources for the offset as far as I'm aware. (and NTP doesn't carry even an unauthenticated one).

GPS carries an offset between UTC and the (leapsecondless) GPS timescale... but the GPS signal is a bit of a pain to get to, and also unauthenticated...