Joe wrote:
> Not really. The problem with leap seconds is that they are too rare
> to allow for comprehensive testing of systems, and so such systems
> tend to fail when a leap second comes along. This is true regardless
> of the chosen OS, and the mission software can also screw up.
That doe
ntpd can easily track SI seconds or "angle time" seconds. The
differences are small enough over a day to be easily amortized.
It would not be all that difficult to create an NTPv5 protocol (for
example) that would include "timescale" as a parameter. There may be a
way to do this using the v4 pro
a few "local policy" issues to think of (smear, just handle it
at the right time, use a different timescale, ...) but it boils down to
making an evaluation and a decision, then implementing and testing it.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
So I gotta ask.
What's the problem with doing radar and other similar things in GPS time
and keeping "human" time in UTC, with leap seconds?
I mean, sure, years ago timestamps were YYMMDDHHMMSS and those
eventually got bigger, and eventually folks started noticing that things
really got interesti
(Found unsent in my Drafts folder...)
Warner Losh writes:
> I think the real reason that UT1 shouldn't be considered a time scale
> is that it is based on not an imperfect realization of a fixed length
> second, but rather an imperfect realization of a variable (measured by
> oscillations of a fi
help make this happen.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Steve Allen writes:
> On Fri 2014-01-03T15:45:13 -0500, Stephen Scott hath writ:
> > 2.)Video in North America and some other parts of the world is
>
> Is currently described by section 5.3.2.13.1 of
> ATSC-Mobile DTV Standard,
> Part 2 -- RF/Transmission System Characteristics
> Document A/153 Pa
I just landed, and my sleep clock is seriously disrupted.
Rob, the presentation you have from me is likely the one that was
converted to powerpoint, and it didn't convert as well as I expected.
I'll send a PDF version as soon as I can.
--
Harlan Stenn
http://networktimefoundation.o
Warner Losh writes:
> ...
>
> A TAI realization of time_t isn't POSIX, which specifically proscribes
> UTC.
I think you mean "prescribes".
H
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Warner Losh writes:
>
> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>
> >
> >>> Um, that is false. All linux kernels did not crash, in fact NONE of
> >>> mine did.
> >>
> >> "all" here was an overstatement, but the impact of the leap second
> >> should never be "your kernel crashes" even
Warner Losh writes:
>
> On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote:
>
>> Warner Losh writes:
>>>
>>> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>>>
>>>>
>>>>>> Um, that is false. All linux kernels did no
Warner Losh writes:
>
> On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote:
> > The conclusions I draw from the utter lack of any similar reports from
> > non-linux systems are:
> >
> > - either those kernels/libraries did not do leap-second processing, or
> &
m, leave it alone. If people are using a defined name for a
defined purpose and it does not work for them, this group needs to come
up with a new name for the thing they think will solve their problems.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
_
"Clive D.W. Feather" writes:
> Harlan Stenn said:
>> I'm still thinking the answer is "leave existing 'names' alone - if
>> you want TAI use TAI. If you want UTC, use UTC. If you want
>> something new, call it something new."
>>
>
us:
http://nwtime.org/membership/why-join/
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
NTP or
> if they were simply excluded from the pool, but the false leap flags
> seem to be way down by now.
This is almost certainly not a problem with NTP. It is almost certainly
a problem with either a refclock (or a signal being fed to a refclock)
or folks having bad leapsecond data, or
Magnus Danielson writes:
> DNSSEC should be part of a DNS solution for instance.
... and correct time is a requirement for DNSSEC.
H
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
heck a site for
an updated file and download it if needed.
If somebody was to do this under a suitable license, I'll happily add it
to the NTP distribution.
This could be done in addition to any other "leapsecond distribution
approaches."
Just an idea...
--
Harlan Stenn
http://ne
his goes to the apparent lack of OS support for what should be
done when the time "steps" - those sort of events could be reason to
re-evaluate a significant class of timer events, which includes the need
to re-evaluate trust certificates, which may cause a reload of DNS and
other prior
ho would join
such a consortium don't have budget for that either.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
http://queue.acm.org/detail.cfm?id=2717320 for more
information.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
f-concept to get these timestamps used as the core
part of the kernel timekeeping API. There is clearly more work to be
done here. We know how to do this work, we just need technical and
financial support to make it happen.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Joseph Gwinn writes:
> On Sun, 01 Mar 2015 20:35:20 +0000, Harlan Stenn wrote:
> Once people get a system to work, they don't tend to go fixing things
> that ain't broke.
There's breakage they know about and breakage they don't know about...
>>> 2. S
le timescales, so if there is a
GPS timescale that's easy. If other satellite systems use different
timescales then that's perfectly OK too.
As long as there's a way to map these to/from a canonical form
(currently TAI) then we should b
ok at what we're doing and helping out in
any way you are up for. One of the issues that will need more attention
is pre-1972 stuff.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.c
"Poul-Henning Kamp" writes:
>
> In message <20150426160837.ga11...@ucolick.org>, Steve Allen writes:
>
> >Both messages show the conceptual failure that results from
> >Recommendation 460, that is a complete lack of concern for the
> >distinction between UTC and GMT.
>
> You're so cute S
library implementation for user-level stuff, and I
expect we'll have GTSAPI implementations built-in to both a linux kernel
and a BSD kernel.
It will take additional resources that we do not yet have to make these
things happen.
--
Harlan Stenn
http://networktimefoundation.org - be a m
h smaller.
I'll point out that a side issue is that there are HUGE number of
ancient versions of NTP out there and too many folks are being slow to
update. Dealing with leap second additions and deletions will be yet
another incentive to upgrade this software.
--
Harlan Stenn
http://n
Martin,
Cosine smearing might need to be a choice. It's harder to track the
leap second if you get a sample during when both phase and frequency are
changing.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing
Rob,
You are way more polite than I might be.
I do believe, however, that NTF's General Timestamp API project might
help POSIX out here, in that it can map other timescales to UTC,
although going the other direction means one has to know how the POSIX
system handles leap seconds.
POSIX needs at
30 matches
Mail list logo
