On 1/18/2015 7:15 PM, Mike S wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap second, there are 86401 SI seconds in
that year
That clearly should
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap second, there are 86401 SI seconds in
that year, that's the whole point. You may also be interested to l
On 2015-01-18, Mike S wrote:
> On 1/14/2015 3:50 AM, Rob wrote:
>> No, it is the inadvertent decision to use UTC as a monotonic clock that
>> causes the trouble.
>
> UTC is monotonic. It is POSIX time which has discontinuities when it
> tries to represent UTC.
TAI is monotonic and continuous. UT
On 2015-01-18, Mike S wrote:
> On 1/13/2015 11:46 PM, William Unruh wrote:
>
>> That is a translation from seconds to ymdhms. The problem is not there.
>> it is in the UTC seconds.
>> In UTC one second disappears after the leap second, but not before or
>> during. Thus UTC seconds numbering is sim
On 1/14/2015 3:50 AM, Rob wrote:
No, it is the inadvertent decision to use UTC as a monotonic clock that
causes the trouble.
UTC is monotonic. It is POSIX time which has discontinuities when it
tries to represent UTC.
___
questions mailing list
ques
On 1/13/2015 11:46 PM, William Unruh wrote:
That is a translation from seconds to ymdhms. The problem is not there.
it is in the UTC seconds.
In UTC one second disappears after the leap second, but not before or
during. Thus UTC seconds numbering is simply disconinuous (jumps back) .
UTC jumps
On Linux it worked correctly... That is?
Thanks!
-- bronto
Il 16/gen/2015 16:30 "Martin Burnicki" ha
scritto:
> I've just ran a few leap second tests with ntpd 4.2.8 under Windows and
> Linux and found that the leap second is not applied correctly under Windows
> 8 and 8.1.
>
> Under windows 7
Martin,
If a fix is found for this in time I'll get it in 4.2.8p1.
H
Martin Burnicki writes:
> I've just ran a few leap second tests with ntpd 4.2.8 under Windows and
> Linux and found that the leap second is not applied correctly under
> Windows 8 and 8.1.
>
> Under windows 7 and on a Linux
Jochen Bern writes:
> ...
>
> We all know that the current NTP protocol leans toward UTC, and
> doesn't address any leap seconds except the one that might be at hand
> right now. In recent posts to this list, I've read about plans for an
> NTPng that allows for different timescales, but still sug
I've just ran a few leap second tests with ntpd 4.2.8 under Windows and
Linux and found that the leap second is not applied correctly under
Windows 8 and 8.1.
Under windows 7 and on a Linux system this worked correctly.
I've opened a bug to track this:
https://bugs.ntp.org/show_bug.cgi?id=2732
On 01/16/2015 05:41 AM, Chris Adams wrote:
> I think one problem with OS clocks in TAI is that counting it correctly
> requires active/on-going maintenance at unknownable intervals for all
> systems that use any form of timestamps (including for example anything
> that uses network file systems).
On 2015-01-16, Chris Adams wrote:
> Once upon a time, Phil W Lee said:
>>For the tiny number of programs which really need UTC (not TAI), it
>>would just be a different number, but the only thing I know of which
>>really needs UTC rather than TAI would be programs to assist with
>>astronomy or a
Terje Mathisen wrote:
OK, so exactly as encoded in the "right" zone info, there is no leap
second until the table is updated/patched.
And yet there is no expiration date in the TZDB's leap second file
(which is also used for the "right" time zones), so you don't know if
there is no upcoming l
Terje Mathisen writes:
> cmad...@cmadams.net (Chris Adams) wrote:
> > Also, you can't properly represent future timestamps (necessary for some
> > things) as seconds since an epoch, and that's pretty widely used. By
> > that I mean that the number of seconds between 2015-06-30 23:59:00 and
> > 201
cmad...@cmadams.net (Chris Adams) wrote:
Once upon a time, Phil W Lee said:
For the tiny number of programs which really need UTC (not TAI), it
would just be a different number, but the only thing I know of which
really needs UTC rather than TAI would be programs to assist with
astronomy or as
David Woolley wrote:
On 15/01/15 07:56, Terje Mathisen wrote:
Did we have a leap second last June? Or did you intend to check for 2015?
Oops. I did get it right in the dry run, but not in the run I actually
used:
david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015
86400
Once upon a time, Phil W Lee said:
>For the tiny number of programs which really need UTC (not TAI), it
>would just be a different number, but the only thing I know of which
>really needs UTC rather than TAI would be programs to assist with
>astronomy or astral navigation.
I think one problem wi
On 15/01/15 07:56, Terje Mathisen wrote:
Did we have a leap second last June? Or did you intend to check for 2015?
Oops. I did get it right in the dry run, but not in the run I actually
used:
david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015
86400 seconds'
Wed Jul 1
David Woolley wrote:
On 14/01/15 16:37, Terje Mathisen wrote:
The calls I'm thinking of are those you make to convert an OS-supplied
time_t (file) system timestamp to YMDHMS etc.
Those calls have no need to be in the kernel, and they are not in
Unix/Linux systems.
The standard GetSystemTime*
On 14/01/15 16:37, Terje Mathisen wrote:
The calls I'm thinking of are those you make to convert an OS-supplied
time_t (file) system timestamp to YMDHMS etc.
Those calls have no need to be in the kernel, and they are not in
Unix/Linux systems.
I.e. even Windows (which uses a seconds-based ti
On 2015-01-14, Erwan David wrote:
> Harlan Stenn disait le 01/13/15 que :
>
>> Martin Burnicki writes:
>>> Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach,
where they smear the leap second over something like a day, might be
one of the better
Paul wrote:
On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen
wrote:
By _far_ the largest majority of all system time calls are asking for the
_current_ time, right?
Are there (common) systems that have kernel calls for other than the
current time?
The calls I'm thinking of are those you
Jochen Bern wrote:
On 01/13/2015 09:33 AM, Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach, where
they smear the leap second over something like a day, [...]
For distributed logging you have to use the same method for every single
node, but that is the ca
Jochen Bern wrote:
On 01/13/2015 09:33 AM, Terje Mathisen wrote:
I hate to admit it, but I'm starting to believe Google's approach, where
they smear the leap second over something like a day, [...]
For distributed logging you have to use the same method for every single
node, but that is the ca
On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen
wrote:
> By _far_ the largest majority of all system time calls are asking for the
> _current_ time, right?
Are there (common) systems that have kernel calls for other than the
current time?
___
questio
On 01/13/2015 09:33 AM, Terje Mathisen wrote:
> I hate to admit it, but I'm starting to believe Google's approach, where
> they smear the leap second over something like a day, [...]
>
> For distributed logging you have to use the same method for every single
> node, but that is the case today as
William Unruh wrote:
Now you could have the computer run in TAI and then do the translation
in userland software. But of course since most things expect utc
seconds, every call to the clock would require you figuring out what the
offset from utc to tai is, and subtract that number, making time sy
William Unruh wrote:
> That is a translation from seconds to ymdhms. The problem is not there.
> it is in the UTC seconds.
> In UTC one second disappears after the leap second, but not before or
> during. Thus UTC seconds numbering is simply disconinuous (jumps back) .
> And it is that which is th
Erwan David writes:
> Harlan Stenn disait le 01/13/15 que :
>
> > Martin Burnicki writes:
> >> Terje Mathisen wrote:
> >>> I hate to admit it, but I'm starting to believe Google's approach,
> >>> where they smear the leap second over something like a day, might be
> >>> one of the better workarou
Harlan Stenn disait le 01/13/15 que :
> Martin Burnicki writes:
>> Terje Mathisen wrote:
>>> I hate to admit it, but I'm starting to believe Google's approach,
>>> where they smear the leap second over something like a day, might be
>>> one of the better workarounds.
>
> This won't work for a bun
On 2015-01-14, Phil W Lee wrote:
> brian utterback considered Mon, 12 Jan
> 2015 04:29:21 GMT the perfect time to write:
>
>>
>>On 1/11/2015 4:56 PM, Rob wrote:
>>> Michael Moroney wrote:
If I have a system synchronized with a public NTP source, which is
synchronized with an atomic cl
Harlan Stenn writes:
> David Taylor writes:
> > On 13/01/2015 08:58, Hal Murray wrote:
> > []
> > > How often do people working with log files from 2 systems care about
> > > fractions of a second?
>
> I have spoken with enterprise users who have to correlate logging
> timestamps between 50-200 (o
Martin Burnicki writes:
> Terje Mathisen wrote:
>> I hate to admit it, but I'm starting to believe Google's approach,
>> where they smear the leap second over something like a day, might be
>> one of the better workarounds.
This won't work for a bunch of folks. Other folks *hate* this approach
be
David Taylor writes:
> On 13/01/2015 08:58, Hal Murray wrote:
> []
> > How often do people working with log files from 2 systems care about
> > fractions of a second?
I have spoken with enterprise users who have to correlate logging
timestamps between 50-200 (or more) systems in cloud deployments
Harlan Stenn wrote:
Marco Marongiu writes:
On 12/01/15 06:10, William Unruh wrote:
I also admit I do not know how windows impliments leap
seconds.
I don't have a reference, but I remember that at the time of the latest
leap second I read that Windows will half the clock speed at 23:59:59 so
t
Terje Mathisen wrote:
Brian Utterback wrote:
On 1/12/2015 6:29 AM, Mike Cook wrote:
Not true. That would violate POSIX. There is no "properly implements",
or "right thing".
Perhaps you're unaware that POSIX isn't the One True Operating System
specification.
"Properly implements" means it foll
Marco Marongiu wrote:
On 12/01/15 11:48, Martin Burnicki wrote:
Fortunately Dave Hart had some time to have a closer look at this, and
fix it for 4.2.6, so unless something has been broken again in the mean
time it should be fixed in 4.2.6 and later, and should work correctly.
Let me understan
On 13/01/2015 08:58, Hal Murray wrote:
[]
How often do people working with log files from 2 systems care about
fractions of a second?
I am comparing log files with a user in another country, where we are
looking at errors in satellite data. As there can be many messages per
second, using NTP
Hal Murray writes:
> [Context is google-smear.]
>
> > For distributed logging you have to use the same method for every single
> > node, but that is the case today as well. :-(
>
> > I.e. with one domain smearing and another stepping, the times between them
> > will be skewed over the entire sme
[Context is google-smear.]
> For distributed logging you have to use the same method for every single
> node, but that is the case today as well. :-(
> I.e. with one domain smearing and another stepping, the times between them
> will be skewed over the entire smearing period.
How often do peop
Brian Utterback wrote:
On 1/12/2015 6:29 AM, Mike Cook wrote:
Not true. That would violate POSIX. There is no "properly implements",
or "right thing".
Perhaps you're unaware that POSIX isn't the One True Operating System
specification.
"Properly implements" means it follows the well defined, 4
A "useful" application of a leap second for POSIX and Windows systems is
something I believe the General Timestamp API handles pretty well.
There are some slides about halfway in to
http://www.cacr.caltech.edu/futureofutc/aas223/presentations/2-3-NetworkTimeInfrastructure.pptx.pdf
that talk about
Marco Marongiu writes:
> On 12/01/15 06:10, William Unruh wrote:
> > I also admit I do not know how windows impliments leap
> > seconds.
>
> I don't have a reference, but I remember that at the time of the latest
> leap second I read that Windows will half the clock speed at 23:59:59 so
> that it
On 1/12/2015 6:29 AM, Mike Cook wrote:
Not true. That would violate POSIX. There is no "properly implements",
or "right thing".
Perhaps you're unaware that POSIX isn't the One True Operating System
specification.
"Properly implements" means it follows the well defined, 40 year old normative
s
On 12/01/15 16:10, Marco Marongiu wrote:
If so, does it also mean that it would do the same when you disable the
kernel discipline by adding a disable kernel in ntp.conf?
(Or by trying to disable stepping. A lot of people seem to run systems
that are incompatible with the use of the kernel di
William Unruh wrote:
> So, there are a bunch of proposals. stop the clock a la Mills
> (delivering times that always increase but very very slowly during that
> second).
> double the rate of the clock during the two seconds around the leap.
> Have the clock run in TAI and put the leapsecond hand
On 01/12/2015 04:55 PM, William Unruh wrote:
> So, there are a bunch of proposals.
> 1. stop the clock a la Mills (delivering times that always increase
>but very very slowly during that second).
> 2. double the rate of the clock during the two seconds around the
>leap. Have the clock run
On Mon, Jan 12, 2015 at 12:46 AM, Mike Cook wrote:
> > Why do folks mention leap seconds on this list?
> part of the NTP protocol deals with the scheduling insertion/deletion of
> leap seconds.
>
I should have phrased that differently. Or just let it go.
>
> > Why do people point to leap-s
On 2015-01-12, Michael Moroney wrote:
> Rob writes:
>
>>Michael Moroney wrote:
>>> If I have a system synchronized with a public NTP source, which is
>>> synchronized with an atomic clock that provides leap second info, and
>>> I am watching carefully, what will happen when the leap second hits
On 12/01/15 11:48, Martin Burnicki wrote:
> Fortunately Dave Hart had some time to have a closer look at this, and
> fix it for 4.2.6, so unless something has been broken again in the mean
> time it should be fixed in 4.2.6 and later, and should work correctly.
Let me understand: you mean that in
Michael Moroney wrote:
> Rob writes:
>
>>Michael Moroney wrote:
>>> If I have a system synchronized with a public NTP source, which is
>>> synchronized with an atomic clock that provides leap second info, and
>>> I am watching carefully, what will happen when the leap second hits? Will
>>> my
Martin Burnicki wrote:
> Rob schrieb:
>> Mike S wrote:
>>> On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system will "stop"
for a second at the last second of June.
>>>
>>
Rob writes:
>Michael Moroney wrote:
>> If I have a system synchronized with a public NTP source, which is
>> synchronized with an atomic clock that provides leap second info, and
>> I am watching carefully, what will happen when the leap second hits? Will
>> my system suddenly find its clock o
Paul wrote:
On Sun, Jan 11, 2015 at 11:34 PM, brian utterback <
brian.utterb...@oracle.com> wrote:
On 1/11/2015 10:40 PM, William Unruh wrote:
Well, actually as I understand it, ntpd does stop the cclock for that
second
That is not the case. That is the behavior that the kernel reference
co
Rob schrieb:
Mike S wrote:
On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system will "stop"
for a second at the last second of June.
A system which properly implements leap seconds
Mike S wrote:
On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system will "stop"
for a second at the last second of June.
A system which properly implements leap seconds will do no such
>>
>> Not true. That would violate POSIX. There is no "properly implements",
>> or "right thing".
>
> Perhaps you're unaware that POSIX isn't the One True Operating System
> specification.
>
> "Properly implements" means it follows the well defined, 40 year old
> normative specification for ha
Marco Marongiu wrote:
On 12/01/15 06:10, William Unruh wrote:
I also admit I do not know how windows impliments leap
seconds.
The Windows operating system by itself is not aware of any leap seconds,
as far as I know.
Due to this fact, I opened a bugzilla issue back in 2005
https://bugs.ntp.
On 1/11/2015 11:32 PM, brian utterback wrote:
On 1/11/2015 9:44 PM, Mike S wrote:
On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system will "stop"
for a second at the last second of J
brian utterback wrote:
>
> On 1/11/2015 4:56 PM, Rob wrote:
>> Michael Moroney wrote:
>>> If I have a system synchronized with a public NTP source, which is
>>> synchronized with an atomic clock that provides leap second info, and
>>> I am watching carefully, what will happen when the leap secon
Mike S wrote:
> On 1/11/2015 7:16 PM, William Unruh wrote:
>> If that public source is responsible it will pass on to your
>> system the fact that there is a leapsecond, and your system will "stop"
>> for a second at the last second of June.
>
> A system which properly implements leap seconds will
On 12/01/15 06:10, William Unruh wrote:
> I also admit I do not know how windows impliments leap
> seconds.
I don't have a reference, but I remember that at the time of the latest
leap second I read that Windows will half the clock speed at 23:59:59 so
that it reaches 00:00:00 at the right time.
On Sun, Jan 11, 2015 at 11:34 PM, brian utterback <
brian.utterb...@oracle.com> wrote:
>
> On 1/11/2015 10:40 PM, William Unruh wrote:
> > Well, actually as I understand it, ntpd does stop the cclock for that
> > second
>
> That is not the case. That is the behavior that the kernel reference
> cod
On 2015-01-12, brian utterback wrote:
>
> On 1/11/2015 10:40 PM, William Unruh wrote:
>> On 2015-01-12, Mike S wrote:
>>> On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system w
On 1/11/2015 10:40 PM, William Unruh wrote:
> On 2015-01-12, Mike S wrote:
>> On 1/11/2015 7:16 PM, William Unruh wrote:
>>> If that public source is responsible it will pass on to your
>>> system the fact that there is a leapsecond, and your system will "stop"
>>> for a second at the last second
On 1/11/2015 9:44 PM, Mike S wrote:
> On 1/11/2015 7:16 PM, William Unruh wrote:
>> If that public source is responsible it will pass on to your
>> system the fact that there is a leapsecond, and your system will "stop"
>> for a second at the last second of June.
>
> A system which properly implem
On 1/11/2015 4:56 PM, Rob wrote:
> Michael Moroney wrote:
>> If I have a system synchronized with a public NTP source, which is
>> synchronized with an atomic clock that provides leap second info, and
>> I am watching carefully, what will happen when the leap second hits? Will
>> my system sudd
On 2015-01-12, Mike S wrote:
> On 1/11/2015 7:16 PM, William Unruh wrote:
>> If that public source is responsible it will pass on to your
>> system the fact that there is a leapsecond, and your system will "stop"
>> for a second at the last second of June.
>
> A system which properly implements le
On 1/11/2015 7:16 PM, William Unruh wrote:
If that public source is responsible it will pass on to your
system the fact that there is a leapsecond, and your system will "stop"
for a second at the last second of June.
A system which properly implements leap seconds will do no such thing.
It wil
On 2015-01-11, Michael Moroney wrote:
> If I have a system synchronized with a public NTP source, which is
> synchronized with an atomic clock that provides leap second info, and
> I am watching carefully, what will happen when the leap second hits? Will
> my system suddenly find its clock off b
Michael Moroney wrote:
> If I have a system synchronized with a public NTP source, which is
> synchronized with an atomic clock that provides leap second info, and
> I am watching carefully, what will happen when the leap second hits? Will
> my system suddenly find its clock off by 1 second and
If I have a system synchronized with a public NTP source, which is
synchronized with an atomic clock that provides leap second info, and
I am watching carefully, what will happen when the leap second hits? Will
my system suddenly find its clock off by 1 second and slowly drift to
the accurate tim
Why do folks mention leap seconds on this list?
Why do people point to leap-seconds.NTPtimestamp instead of just
leap-seconds.list?
My five line leap second file with comments and one extra line for
(completely unnecessary) context.
#$ 3629404800
#@ 3660249600
3550089600 35 #
NIST updated ftp://time.nist.gov/pub/leap-seconds.list linked to
leap-seconds.3629404800
On 2015-01-05 07:29, Marco Marongiu wrote:
Get ready, fellows. It's coming again.
-- bronto
Forwarded Message
Subject: Bulletin C number 49
Date: Mon, 05 Jan 2015 14:25:49 +0100
From: I
Get ready, fellows. It's coming again.
-- bronto
Forwarded Message
Subject: Bulletin C number 49
Date: Mon, 05 Jan 2015 14:25:49 +0100
From: IERS EOP Product Center
Reply-To: IERS EOP Product Center
To: bulc.i...@obspm.fr
INTERNATIONAL EARTH ROTATION AND REFERENCE SY
The 4.2.7 code uses the majority rule for leap indicator when processing
network peers/servers/ref clock's LI bits (with the leap_vote counter).
However, the same logic is not used when processing the leap data from
peers/servers via auto-key protocol. In the "case CRYPTO_LEAP | CRYPTP_RESP"
(n
Terje Mathisen wrote:
Stephen Yu wrote:
Hello,
In the dev release ntp-dev-4.2.7p361, the file ntp_timer.c has the
following code to set "sys_leap".
if (leapsec > 0) { leapsec--; if (leapsec == 0) { sys_leap =
LEAP_NOWARNING; . } else { if (leapsec <
DAY) sys_leap = LEAP
On 2013-03-20, Harlan Stenn wrote:
> To date there has never been a deleted leap second and one is not
> expected.
>
> It is arguable that we should code for this possibility in case one
> happens, and on the flip side of that we're introducing the potential
> for something else to break.
There w
Stephen Yu wrote:
Hello,
In the dev release ntp-dev-4.2.7p361, the file ntp_timer.c has the
following code to set "sys_leap".
if (leapsec > 0) { leapsec--; if (leapsec == 0) { sys_leap =
LEAP_NOWARNING; . } else { if (leapsec <
DAY) sys_leap = LEAP_ADDSECOND; if (leap_ta
He was saying that yes, your assumption that leap seconds are added only
is a very reasonable one. However, the leapsecond agreement says that
they can be both added and deleted, and ntpd should certainly allow for
both. Note that many of the refclocks do allow for the leapsecond to be
deleted as
] Leap second question
To date there has never been a deleted leap second and one is not expected.
It is arguable that we should code for this possibility in case one happens,
and on the flip side of that we're introducing the potential for something else
to break.
While some earthquakes
To date there has never been a deleted leap second and one is not
expected.
It is arguable that we should code for this possibility in case one
happens, and on the flip side of that we're introducing the potential
for something else to break.
While some earthquakes could effectively "decrease" th
G, or LEAP_ADDSECOND.
Thanks,
Stephen
-Original Message-
From: Chuck Swiger [mailto:cswi...@mac.com]
Sent: Wednesday, March 20, 2013 10:18 AM
To: Stephen Yu
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] Leap second question
Hi--
On Mar 19, 2013, at 6:15 PM, Stephen Yu wrote:
&
Hi--
On Mar 19, 2013, at 6:15 PM, Stephen Yu wrote:
> The question is why "sys_leap = LEAP_ADDSECOND" is unconditional. Is this
> based on the prior knowledge that earth always rotates slower? In other word,
> could it ever be "sys_leap = LEAP_DELSECOND"?
Over the long term, the earth's rotatio
Hello,
In the dev release ntp-dev-4.2.7p361, the file ntp_timer.c has the following
code to set "sys_leap".
if (leapsec > 0) {
leapsec--;
if (leapsec == 0) {
sys_leap = LEAP_NOWARNING;
.
} else {
On Wed, Aug 22, 2012 at 13:29 UTC, Santi Saez wrote:
> After making some tests with different ntpd versions, I have found that
> "leap second" fields are only forwarded on 4.2.4, and it doesn't work after
> 4.2.6, still don't know the reason or if I need a special configuration.
I suspect the dif
El 21/08/12 23:24, E-Mail Sent to this address will be added to the
BlackLists escribió:
Run the same version on all servers / clients under your control?
{Perhaps even a current version.}
After making some tests with different ntpd versions, I have found that
"leap second" fields are only
El 14/08/12 12:34, Santi Saez escribió:
I have just found that leap-second flag is forwarded from the "master"
to the "client" without problems on CentOS-6 boxes (running
4.2.4p8-2), but with the same configuration it doesn't work on Debian
Squeeze (4.2.6.p2+dfsg-1+b1). If I query ntpd it retu
Hello,
I'm making some tests with "leapfile" feature on ntpd to send fake
leap-seconds and ensure our Linux platform is resilient to the bug :)
Lab is quite simple: a "master" server with local clock running ntpd
with leapfile feature, and a "client" system also running ntpd that
connects to
Folks, and especially people who know the ntpd code,
We are now nearly halfway through August, and I'm wondering where we
stand on the issue of bogus leap seconds. We had one at the beginning
of this month for unknown reasons - but they seem like they could have
stemmed from an ntpd bug: http
On 6/30/2012 17:09, A C wrote:
It appears that my system did not respond well to the leap second.
The GPS has not yet received the leap second notification via the
satellites (it is currently still reporting an offset of 15 seconds).
The leap second was inserted by ntpd according to the leap fil
It appears that my system did not respond well to the leap second.
The GPS has not yet received the leap second notification via the
satellites (it is currently still reporting an offset of 15 seconds).
The leap second was inserted by ntpd according to the leap file and then:
Jun 30 23:59:58
If your ntpd is relying upon other NTP servers (that is, is stratum 2
or higher), it will not announce the pending leap second starting
exactly at midnight UTC in a few minutes, but should within a few
polling intervals. With the default maximum interval of 1024 seconds
being about 17 minutes, by
On 6/29/2012 16:57, Dave Hart wrote:
I know, leap second preparedness is like sneeze preparedness to people
who have a life. But if you care about the pending hole in computers'
timeline, in about 2 minutes ntpd systems around the world will begin
announcing leap=01 instead of leap=00. If you a
I know, leap second preparedness is like sneeze preparedness to people
who have a life. But if you care about the pending hole in computers'
timeline, in about 2 minutes ntpd systems around the world will begin
announcing leap=01 instead of leap=00. If you are responsible for any
ntpd instances,
On 2012-05-29, Alan J Rosenthal wrote:
> Marco Marongiu writes:
>>The question is: does it happen at 00:00:00 UTC (so it must be shifted
>>ahead/behind depending on the timezone)
I believe it occurs at the second before 00:00:00 (ie, whatever happens,
it finishes at that time)
>
> Yes... ima
Marco Marongiu writes:
>The question is: does it happen at 00:00:00 UTC (so it must be shifted
>ahead/behind depending on the timezone)
Yes... imagine how gnarly it would be if two timezones normally (say) 7200
seconds apart were temporarily 7201 or 7199 seconds apart!
_
On May 25, 4:18 am, Marco Marongiu wrote:
> The question is: does it happen at 00:00:00 UTC (so it must be shifted
> ahead/behind depending on the timezone) or, by convention, it happens at
> 00:00:00 at the local timezone?
The ITU-R recommendation is the origin of the practice of leap
seconds, a
On 5/25/2012 7:18 AM, Marco Marongiu wrote:
...on June 30th/July 1st transition, so we'll have:
June 30th 23:59:59
June 30th 23:59:60
July 1st 00:00:00
The question is: does it happen at 00:00:00 UTC (so it must be shifted
ahead/behind depending on the timezone) or, by convention, it happens a
On 25/05/2012 15:01, Miguel Gonçalves wrote:
> It happens at 23:59:59 UTC:
> ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
>
> The bulletin states that the leap second is introduced at the end of
> June so 00:00:00 is not a possibility because it is already July.
thanks a lot Miguel!
Ciao
-
101 - 200 of 361 matches
Mail list logo
