Making every (leap) second count with our new public NTP servers • Hacker News Board

Re: Making every (leap) second count with our new public NTP servers

#61

Post by Pharylon » Thu, Dec 01, 2016, 5:29 PM UTC

tankenmate wrote: post #54

ryanobjc wrote: post #24

Earlier quoted context omitted.

It isn't even so simple as "work with others" - the other people involved here aren't even thinking at this level. Leap seconds are an ugly hack that were inserted without any thought as to the impact on computer systems. We should not use them, they exist as a vanity project imo. Remember when leap seconds caused ALL JVMs to lock up until restarted? Or kernel bugs? ick!

In effect leap time has been used since the middle on the first millennium BC, the Babylonians discovered the difference between mean solar time and sidereal time and had corrected clocks ever since then. In order to reconcile relative earth surface time with earth mean solar time meant that time had to be inserted or removed somewhere. In the spirit of DevOps small frequent changes are better than big infrequent cha…

Leap minutes could be publicized a century before being implemented, making sure all libraries accounted for the, just like leap hours.

Re: Making every (leap) second count with our new public NTP servers

#62

Post by klodolph » Thu, Dec 01, 2016, 5:51 PM UTC

creshal wrote: post #43

klodolph wrote: post #42

Earlier quoted context omitted.

Then NTP has already failed. Most systems are already incapable of agreeing on whether it is 23:59:59 or 23:59:60 on days with leap seconds. There is simply not an API that will let you distinguish the two. It is better to be deliberately wrong in a controlled fashion than to be accidentally wrong because you never expected your clock to be non-monotonic. You seem to be arguing for the status quo, are you aware of ju…

What is your definition of "most systems"? Because we had very few (if somewhat high-profile) leap second bugs since its introduction in 1972.

Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing.

Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization.

I'm not even talking about bugs here—these are straight up design flaws.

Re: Making every (leap) second count with our new public NTP servers

#63

Post by azinman2 » Thu, Dec 01, 2016, 6:11 PM UTC

russdill wrote: post #25

leni536 wrote: post #23

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

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.

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.

Re: Making every (leap) second count with our new public NTP servers

#64

Post by kazinator » Thu, Dec 01, 2016, 6:53 PM UTC

paulajohnson wrote: post #39

russdill wrote: post #25

Earlier quoted context omitted.

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.

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.

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.

Re: Making every (leap) second count with our new public NTP servers

#65

Post by kazinator » Thu, Dec 01, 2016, 7:00 PM UTC

azinman2 wrote: post #63

russdill wrote: post #25

Earlier quoted context omitted.

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.

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.

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.

Re: Making every (leap) second count with our new public NTP servers

#66

Post by JdeBP » Thu, Dec 01, 2016, 8:14 PM UTC

klodolph wrote: post #62

creshal wrote: post #43

Earlier quoted context omitted.

What is your definition of "most systems"? Because we had very few (if somewhat high-profile) leap second bugs since its introduction in 1972.

Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing. Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization. I'm not even talking about bugs here—these are straight up design flaws.

There are actually two reasonable ways of handling leap seconds with gettimeofday(). The first, which is in actual use by a range of people, is to define that the kernel time is actually a TAI-10 count not a UTC count. Arthur David Olson's "right" timezone system does this. The second is to allow the microseconds count to go up to 2,000,000.

* http://www.madore.org/~david/computers/unix-leap-seconds.htm...

Re: Making every (leap) second count with our new public NTP servers

#67

Post by JdeBP » Thu, Dec 01, 2016, 8:43 PM UTC

ryanobjc wrote: post #24

toast0 wrote: post #20

Earlier quoted context omitted.

I think taking this step unilaterally is the only way it's going to be taken. Given that Google doesn't want to deal with leap seconds [1], and that the standards organizations have been debating removing leap seconds for years, at least they're publicizing what they're doing. [1] for good reasons

It isn't even so simple as "work with others" - the other people involved here aren't even thinking at this level. Leap seconds are an ugly hack that were inserted without any thought as to the impact on computer systems. We should not use them, they exist as a vanity project imo. Remember when leap seconds caused ALL JVMs to lock up until restarted? Or kernel bugs? ick!

> Leap seconds are an ugly hack that were inserted without any thought as to the impact on computer systems.

No. Leap seconds were a rationalization of a prior system that really was ugly for computers. The conversion between TAI and UT(n) that was used before UTC involved table-driven algorithms with multiple rules and microsecond adjustments.

If you thought that six months' notice to add a leap second to /etc/leapsecs.dat is a huge imposition, then you you should try creating a computer system that can cope with rules like "for the next three months, from January the 1st to March the 31st 1964, you must add 0.001296 of a second for each day since 38761 and then add a further 3.240130 seconds".

Ironically, UTC and the leap second system are geared towards the same sort of timekeeping that computers do and away from the civil timekeeping that preceded it: a constant length second that can be measured with oscillators and electronic counters, being the basis for civil time; rather than astronomical calculation.

Re: Making every (leap) second count with our new public NTP servers

#68

Post by JdeBP » Thu, Dec 01, 2016, 9:07 PM UTC

antoncohen wrote: post #56

For people talking about Google unilaterally doing this, it has been common to smear the leap second for the last couple years. Usually companies do it internally by having their NTP servers skew time, either with Chrony or `ntpd -x`. Standards bodies have not been able to react quickly enough to the need to smear the leap second in a consistent way. I'm thankful that Google has decided to run public NTP servers with…

I hope that there are people on standards bodies who remember or learned what it was like before UTC when civil time seconds were not one SI second long, and in effect "smearing" happened all the time.

Re: Making every (leap) second count with our new public NTP servers

#69

Post by fanf2 » Fri, Dec 02, 2016, 12:58 AM UTC

JoshTriplett wrote: post #18

ac29 wrote: post #8

Earlier quoted context omitted.

>Linux timekeeping (which currently handles leap seconds via a 61-second minute instead) Google doesn't think so: "No commonly used operating system is able to handle a minute with 61 seconds"

Some things did go wrong on a few of the previous leap-second injections, and the Linux timekeeping maintainer had talked about changing the approach to handling them (which has already changed at least once in the past). I don't, however, think it makes sense to unilaterally change this, without (any obvious signs of) coordination with the timekeeping maintainers and the maintainers of major NTP servers.

Things go wrong on every leap second, sometimes catastrophically. They go wrong on non-leap-seconds because of falsely advertised leap seconds. They go wrong 4 months before a leap second because a leap indicator got set and some software had an incorrect idea of when it was due.

Never mind the theory, the practice is a clusterfuck.

Re: Making every (leap) second count with our new public NTP servers

#70

Post by jrnichols » Fri, Dec 02, 2016, 1:02 AM UTC

JoshTriplett wrote: post #6

brandmeyer wrote: post #3

> Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and “smear” the extra second across these twenty hours. Holy leaping second, batman! Unilaterally being off by up to a half second from the rest of the world's clocks is a pretty aggressive step. I think I would have preferred to see a resolution made by…

Smearing leap seconds does make sense, but it's an odd step to take unilaterally, rather than coordinating with other NTP servers and with Linux timekeeping (which currently handles leap seconds via a 61-second minute instead).

This seems to be the Google way sometimes. "We're going to take a standard and change it and do things our way. Toodles!" Just like what they did with IMAP & Gmail.