Re: [LEAPSECS] Time math libraries, UTC to TAI

On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit wrote: > Warner Losh wrote: >> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit wrote: >> > 2. Have xtime keep TAI. This has the advantage that it's not at >> >all wrong or kludgey to represent TAI as a simple

Re: [LEAPSECS] alternative to smearing

On Wed, Jan 4, 2017 at 9:36 PM, Steve Summit wrote: > Warner Losh wrote: >> Steve Summit wrote: >> > The requirement for tables (and, correspondingly, the >> > "impossibility" of dealing with future UTC dates more than a few >> > months out) depends on what

Re: [LEAPSECS] alternative to smearing

Warner Losh wrote: > Steve Summit wrote: > > The requirement for tables (and, correspondingly, the > > "impossibility" of dealing with future UTC dates more than a few > > months out) depends on what you're trying to do... > > In particular, if right now it's

Re: [LEAPSECS] Time math libraries, UTC to TAI

Warner Losh wrote: > On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit wrote: > > 2. Have xtime keep TAI. This has the advantage that it's not at > >all wrong or kludgey to represent TAI as a simple count of > >seconds since the epoch, which of course xtime already is. > >

Re: [LEAPSECS] Time math libraries, UTC to TAI

On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit wrote: > 2. Have xtime keep TAI. This has the advantage that it's not at >all wrong or kludgey to represent TAI as a simple count of >seconds since the epoch, which of course xtime already is. >The objection, as

Re: [LEAPSECS] alternative to smearing

> The requirement for tables (and, correspondingly, the > "impossibility" of dealing with future UTC dates more than a few > months out) depends on what you're trying to do. You can *talk* > about the dates, and you can do interval arithmetic with a > precision of days, hours, or minutes,

Re: [LEAPSECS] Time math libraries, UTC to TAI

Martin Burnicki wrote: > If we don't look only at the kernel and ntpd, but also consider PTP, > then there's still the question if if wouldn't be better to let the > kernel time run on TAI, and derive true and/or smeared UTC from it. Right. At first when I was trying to implement CLOCK_UTC, I

Re: [LEAPSECS] alternative to smearing

t...@leapsecond.com (Tom Van Baak), > The February leap day is a useful analogy when describing leap seconds > to non-technical people. But when you get into the details the two are > vastly different. A well-written list, thanks. One quibble, though: > 2) Past dates involving February can be

Re: [LEAPSECS] alternative to smearing

Oops; typo; sorry; I'm an idiot by a factor of millions. s/seconds/years/ and it should read: 9) Exposing citizens to leap days is near universal. Printed and computer calendars have no trouble with that extra day. Almost every child learns about leap years during their schooling. Some people

Re: [LEAPSECS] Leap second smearing test results

> Unfortunately not. More tests to be done. Especially the cases where the > server sends "poll 4" to its clients during the smear interval. On the one > hand this seems to have an affect on the client, in that the client's poll > interval decreases more than without it. On the other hand, why

Re: [LEAPSECS] alternative to smearing

Tom Van Baak said: > Because most people don't live in Greenwich Greenwich isn't the only relevant place. I think I'm probably the person on this list who lives closest to the Prime Meridian, at 0.027066 degrees east according to Google Maps (I used to live at 0.011605 but moved house). I'm in

Re: [LEAPSECS] alternative to smearing

> There's a big difference between these two: February varies in a fixed, > regular manner, whereas UTC days are unpredictable. The Gregorian > calendar is of the arithmetic variety, whereas UTC is an observational > calendar. UTC is qualitatively more difficult to handle. > > -zefram Agreed.

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

Hal Murray wrote: > > Suppose I want to wait until some UTC date/time more than 6 months in the > future. A library routine doesn't have to compute how many seconds to wait > right now. It can break it down into chunks. Wait until the current leap > file expires, then

Re: [LEAPSECS] Leap seconds ain't broken

On Wed, Jan 4, 2017 at 1:46 AM, Martin Burnicki wrote: > I agree it would be good to implement this in an extension field, but > generally care should be taken not to break compatibility. I mean, how > do existing clients act if they receive a packet with unknown

Re: [LEAPSECS] alternative to smearing

On Wed, 2017-01-04 at 19:04 +0100, Preben Nørager wrote: > On Wed, 2017-01-04 at 18:11 +0100, John Sauter wrote: > > "I am curious: since you do not think my moral concern is future > generations, what do you think it is?" > > I think your moral concern is the misguided belief, that abolishing >

Re: [LEAPSECS] alternative to smearing

On Wed, 2017-01-04 at 18:11 +0100, John Sauter wrote: "I am curious: since you do not think my moral concern is future generations, what do you think it is?" I think your moral concern is the misguided belief, that abolishing leap seconds will mean our official time will depend solely on cesium

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: > Tony Finch wrote: > > > > Even though NTP can represent current UTC correctly, it often gets leap > > seconds wrong. It does not give confidence that we will be able to > > reduce bugs by teaching more code about leap seconds, when NTP cares

Re: [LEAPSECS] alternative to smearing

On Wed, 2017-01-04 at 16:29 +0100, Preben Nørager wrote: > On Wed, 2017-01-04 at 15:25 +0100, John Sauter wrote: > > "Preben, You and I disagree on this issue.  For me this is > fundamentally a moral > concern.  I believe that each generation should handle its problems > as > best it can, leaving

Re: [LEAPSECS] alternative to smearing

John Sauter wrote: >I don't regard leap seconds as being a special kind of awful. The >Gregorian calendar has February, which if it had been introduced in >1972 would have been regarded as "awful" for computers because it has a >variable length. There's a big difference between these two:

Re: [LEAPSECS] alternative to smearing

Preben Norager wrote: > The other aspect was the dropping of ten days. I don't know >exactly why the march equinox shall occur allways around march 21. Would >allways around march 11 not have been just as good? There was a sense of there being a "correct" phase alignment between the

Re: [LEAPSECS] alternative to smearing

On Wed, 2017-01-04 at 09:42 -0500, Michael Rothwell wrote: > The Gregorian calendar doesn't mess up how computers keep track of > time, like leap seconds do. Neither do time zones. Leap seconds are > different -- a special kind of awful. I don't regard leap seconds as being a special kind of

Re: [LEAPSECS] alternative to smearing

On Sun, 2017-01-01 at 16:29 -0500, John Sauter wrote: > > If anyone has difficulty extracting the software from the PDF using > okular, e-mail me and I will provide the files separately. Steve Summit has been kind enough to host the code on his web site. The URLs are:

Re: [LEAPSECS] JD & MJD, UT1 & UTC

On Wed, 2017-01-04 at 15:22 +0100, Martin Burnicki wrote: > John Sauter wrote: > > I did some experimenting with this on Fedora 25, Linux kernel > > 4.8.15- 300.fc25.x86_64.  I found that adjtimex sets STA_NANO and > > returns nanoseconds only when NTP has been running for a while.  > > John

Re: [LEAPSECS] alternative to smearing

On Wed, 2017-01-04 at 15:25 +0100, John Sauter wrote: "Preben, You and I disagree on this issue. For me this is fundamentally a moral concern. I believe that each generation should handle its problems as best it can, leaving to the next generation only unforeseen problems. The tension between

Re: [LEAPSECS] alternative to smearing

We don't know how future generations will see the "problem", if leap seconds are abolished. As generations today see it, the "problem" is that without leap seconds the sun is getting ahead or behind the official international timescale, so that the noon transit not normally will occur around 12

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: |Steve Summit wrote: |> Tony Finch wrote: |>> Even though NTP can represent current UTC correctly, it often gets leap |>> seconds wrong. It does not give confidence that we will be able to |>> reduce bugs by teaching more code about leap

Re: [LEAPSECS] JD & MJD, UT1 & UTC

On Wed, 2017-01-04 at 13:40 +0100, Martin Burnicki wrote: > > In the ntpd source code I see a number of places like this: > > #ifdef STA_NANO >   clock_offset = ntv.offset / 1e9; > #else /* STA_NANO */ >   clock_offset = ntv.offset / 1e6; > #endif /* STA_NANO */ > > So this is interpreted here

Re: [LEAPSECS] alternative to smearing

On Wed, 2017-01-04 at 13:57 +0100, Preben Nørager wrote: > We don't know how future generations will see the "problem", if leap > seconds are abolished. As generations today see it, the "problem" is > that without leap seconds the sun is getting ahead or behind the > official international

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Martin Burnicki wrote: |Ask Bjørn Hansen wrote: |> [1] As much as I dislike the leap seconds; smearing is only appropriate |> if you specifically have chosen it so they␦re not supposed to be in the |> pool. | |Agreed. Smearing in the way it is currently done by

Re: [LEAPSECS] Leap second smearing test results

Warner Losh wrote: > I'd be curious what a longer smear time would do? Longer smears would > give a smaller frequency error, which might be easier to digest. It > also copes better with long-polling intervals in clients at the > expense of a longer phase error in the clients. I'd expect that the

Re: [LEAPSECS] Leap second smearing test results

Zefram wrote: > Martin Burnicki wrote: >> I've run some more tests with smearing of leap seconds, > > These new ones, with variable polling interval on the client, are much > more useful than the former ones with fixed polling interval. It seems > to me that these measurements should concentrate

Re: [LEAPSECS] Leap second smearing test results

Again, sorry for replying so late. I've been mostly offline over the holidays. Zefram schrieb: > Martin Burnicki wrote: >> https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf > > This is interesting. The smear actually achieved on the downstream ntp > is a complicated

Re: [LEAPSECS] alternative to smearing

John Sauter wrote: > On Tue, 2017-01-03 at 13:28 -0500, Michael Rothwell wrote: > > Why are you in such favor of leap seconds? > > I regard leap seconds as a reasonable compromise between the needs of > civil time and of science. Civil time needs a clock that tracks the > days and the seasons.

Re: [LEAPSECS] Leap seconds ain't broken

Warner Losh wrote: > That rather sums up the situation today with software. We have a > specific legacy standard called POSIX that's causing all kinds of > issues that pop up when you least expect it (taking out DNS server, > that's impressive), but there's no heir apparent to the standard, > and

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Michael.Deckers. via LEAPSECS wrote: >Why doesn't the NTP message include the TAI - UTC offset used for >the UTC timestamp in the message? Even a faultily configured server >knows when it changes this offset, and it could help avoid the >interpretation of incorrect warning bits.

Re: [LEAPSECS] JD & MJD, UT1 & UTC

John Sauter wrote: > On Wed, 2017-01-04 at 15:22 +0100, Martin Burnicki wrote: >> John Sauter wrote: >>> I did some experimenting with this on Fedora 25, Linux kernel >>> 4.8.15- 300.fc25.x86_64. I found that adjtimex sets STA_NANO >>> and returns nanoseconds only when NTP has been running for a

Re: [LEAPSECS] alternative to smearing

Michael Rothwell wrote: > The Gregorian calendar doesn't mess up how computers keep track of time, > like leap seconds do. Neither do time zones. Leap seconds are different > -- a special kind of awful. I think this depends on what your basic time is, and what time you derive from it. If the

Re: [LEAPSECS] alternative to smearing

The Gregorian calendar doesn't mess up how computers keep track of time, like leap seconds do. Neither do time zones. Leap seconds are different -- a special kind of awful. On Wed, Jan 4, 2017 at 9:25 AM, John Sauter < john_sau...@systemeyescomputerstore.com> wrote: > On Wed, 2017-01-04 at 13:57

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-04 09:03, Martin Burnicki wrote: I think this you statement isn't quite fair. If a web server delivered a page with broken HTML code you wouldn't blame the web server daemon, e.g. apache, would you? It's the task of the web server admin to configure the server correctly and make

Re: [LEAPSECS] JD & MJD, UT1 & UTC

John Sauter wrote: > I did some experimenting with this on Fedora 25, Linux kernel > 4.8.15- 300.fc25.x86_64. I found that adjtimex sets STA_NANO and > returns nanoseconds only when NTP has been running for a while. > John Sauter (john_sau...@systemeyescomputerstore.com) Ah, interesting. Did

[LEAPSECS] Nope, still not broken

On Jan 3, 2017, at 9:51 AM, Warner Losh wrote: > On a purely schadenfreude note: I find it extremely ironic that there are any > telescopes that have issues with a leap second since they are the primary > beneficiary of this peculiar dance we do upon occasion. The point of

Re: [LEAPSECS] JD & MJD, UT1 & UTC

Martin Burnicki wrote: >Yes, but the advantage of a nonnormalized tv_nsec field is that it can >be used with "legacy" structures A non-normalised tm_sec has that advantage too. >On the other hand, this may break existing applications which aren't >aware that the number in tv_nsec can exceed

Re: [LEAPSECS] Time math libraries, UTC to TAI

Steve Summit wrote: > Martin Burnicki wrote: >> IMO another clock type to be used with clock_gettime() would help, as >> already proposed by Markus Kuhn (there was a link to this in a recent >> post here), which could be used by new or actively maintained software. > > Sure. (But are you talking

Re: [LEAPSECS] Time math libraries, UTC to TAI

Zefram wrote: > Martin Burnicki wrote: >> Of course it would be great if there was an API call which executes fast >> to yield a high performance, and returns a timestamp plus an associated >> status code consistently, in an atomic operation. > > A read-only adjtimex() does return all of this

Re: [LEAPSECS] JD & MJD, UT1 & UTC

Zefram wrote: > Steve Summit wrote: >> And this is eerily similar to the idea of using a struct >> timespec with a nonnormalized tv_nsec field. > > For that matter, tm_sec==60 is the same class of trick too. We're just > varying at which digit position we stuff in an out-of-radix value. Yes,

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > It's pretty embarrassing that one of our main time distribution > systems routinely screws up leap seconds. And it's even more embarrassing that the maintainers of such an important piece of network infrastructure don't get more support from vendors, even big ones which have

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Steve Summit wrote: > Tony Finch wrote: >> Even though NTP can represent current UTC correctly, it often gets leap >> seconds wrong. It does not give confidence that we will be able to >> reduce bugs by teaching more code about leap seconds, when NTP cares >> about time and gets it wrong, and most

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Ask Bjørn Hansen wrote: > [1] As much as I dislike the leap seconds; smearing is only appropriate > if you specifically have chosen it so they’re not supposed to be in the > pool. Agreed. Smearing in the way it is currently done by some Google servers (and ntpd, if configured accordingly) is just

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

Tony Finch wrote: > Warner Losh wrote: >> We have a >> specific legacy standard called POSIX that's causing all kinds of >> issues that pop up when you least expect it > > I haven't mentioned the usual litany of NTP servers getting it wrong, > including servers run by national