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 count of
>> >seconds since the epoch,
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 you're trying to do...
>> > In particul
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 2017-01-05T01:56:13, I can
> > obvious
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.
>
> The problem here, no
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 mentioned here pretty regula
> 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, perfectl
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
lum
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 h
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 a
> 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 doe
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 f
> 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. T
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 try again using the new on
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 extension
> field? Do they just ig
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
>
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 a
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
> > about time and gets it wron
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
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: Februar
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
calen
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 awful
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:
http://www.eskimo.com/~scs/
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 Sauter
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 t
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 mid
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 seconds, when NTP cares
|>> abo
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 a
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 timescal
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 some Google servers
|(and ntp
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 s
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
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 fu
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. Sc
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 n
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.
I
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
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 syst
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
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
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 yo
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 leap seconds is to
Zefram wrote:
> 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.
Sorry, maybe I was not clear enough.
In a struct timespec you can use a nonnormalized tv_nsec f
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 1
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
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 info
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, but
Steve Summit wrote:
> It'd be nice to extend NTP with some kind of "provenance" field
> which could say that a certain server is delivering smeared time.
In fact ntpd also even does so. While smearing is in affect the "refid"
field sent in replies to clients is set to "254.aa.bb.cc", where
"aa.bb.
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 h
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
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 theyre 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
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 time labs. It's pre
51 matches
Mail list logo
