Folks,
I've run some tests with smearing of leap seconds. If you're interested,
you can find the results here:
https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf
Martin
___
questions mailing list
questions@lists.ntp.org
As of today UTC, ntpq -crv should now be reporting something like:
associd=0 status=4419 leap_add_sec, sync_uhf_radio, 1 event, leap_armed,
version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2),
processor=x86, system=Windows, leap=01, stratum=1, precision=-21,
...
If it is not,
On 06/11/2015 08:41 AM, Kashif Mumtaz Tahir wrote:
Dear Jochen,
You extracted description is right , we are at stratum 2 and just syncing
its time with stratum 1 level GPS device.
Litte bit confused with your conclusion. When leap second will happen on GPS
what will the impact on our
)
Regards,
kashif
-Original Message-
From: Jochen Bern [mailto:jochen.b...@linworks.de]
Sent: Wednesday, June 10, 2015 6:43 PM
To: Kashif Mumtaz Tahir
Cc: questions@lists.ntp.org
Subject: Re: Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 06/10/2015 01:27 PM, Kashif
Dear Folks,
Our NTP server is placed at stratum 2 which is syncing its time with uplink
GPS devices ( Which are on stratum 1 ).
Now question is that on June 30th leap second is going to happen, is there
anything we need to change /modify on our startum 2 NTP server and other
clients of
On 10/06/15 13:02, Kashif Mumtaz Tahir wrote:
is there anything we need to change /modify
It depends on what you want to achieve. I am upgrading to 4.2.8p3 and
setting tinker step 0 and disable kernel in the configuration
because I am trying to avoid clock stepping at all cost. What about you?
, 2015 3:14 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 10/06/15 13:02, Kashif Mumtaz Tahir wrote:
is there anything we need to change /modify
It depends on what you want to achieve. I am upgrading to 4.2.8p3 and
setting tinker step 0
On 06/10/2015 01:27 PM, Kashif Mumtaz Tahir wrote:
Dear Macro,
We just want to sync seamless with leap seconds. [...]
Should we need to change/tune anything.
I read your description as:
-- There is a GPS device that actually *speaks NTP* (as opposed to,
e.g., being connected to a server
On Thu, Jun 04, 2015 at 05:52:47PM +0200, Marco Marongiu wrote:
As you may have noticed from my messages in this list, I've also been
running leap second simulations with ntpd on Debian during the past few
weeks. If you're using Debian Linux systems you may find the post I've
just published
Hi there
Miroslav Lichvar, whom you have read several times in this list, has put
together a very nice set of five possible ways to handle the leap second
with both ntpd and chrony.
http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
As you may have noticed
Oh, Jeez. I mean 4.2.2p1.
Sorry for confusion.
Check your vendor docs:
https://access.redhat.com/articles/15145
I'm afraid it contains no relevant information.
(Except that my kernels can freeze.)-:
https://access.redhat.com/articles/199563
or upgrade RHEL or ntp package to current
Mohan Kannekanti writes:
Hi,
We are currently using ntpd version 4.2.4p4.
Please see http://support.ntp.org/bin/view/Dev/ReleaseTimeline and
understand your choice.
You are running software that was released in December of 2006, and was
EOL'd in December of 2009 with 4.2.6, which fixed
Hi Harlan,
Thanks for the information. I understand your points. I'm *only* trying
to be get leap second fixes at the moment as we don't have much time to
test the new ntpd feature across all our platforms.
Yes, I'm testing the kernels too.
Also, I'll definitely encourage our folks to be
I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5.
Oh, Jeez. I mean 4.2.2p1.
Sorry for confusion.
Gabor
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On 2015-06-01 07:41, Kiss Gábor wrote:
I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5.
Oh, Jeez. I mean 4.2.2p1.
Sorry for confusion.
Check your vendor docs:
https://access.redhat.com/articles/15145
https://access.redhat.com/articles/199563
or upgrade RHEL or ntp
=?ISO-8859-15?Q?Kiss_G=E1bor?= writes:
I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5.
Oh, Jeez. I mean 4.2.2p1.
Sorry for confusion.
http://support.ntp.org/bin/view/Dev/ReleaseTimeline
We've only fixed 2,600-3,000 issues in the 4 releases of NTP since 4.2.2
was
Dear folks,
I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5.
I try to manage the leap second coming at end of June but I have partial
success only.
Now ntpd at least finds the leap-seconds.3629404800 file
but I guess it gets confused:
$ ntpq -c rv 0 leap,tai,leapsec,expire
On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote:
On 12/05/15 11:28, Marco Marongiu wrote:
Hi there
In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in
the future less than 28 days, the leap warning bits are set.
What are the practical consequences
On 13/05/15 13:23, Miroslav Lichvar wrote:
I'm not sure what exactly are you asking here. Do you see in your
testing or the source code something different from what is described
in the document?
No, I am trying to understand if what I understand* from the
documentation is correct.
* sorry
On 13/05/15 11:03, Miroslav Lichvar wrote:
On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote:
On 12/05/15 11:28, Marco Marongiu wrote:
Hi there
In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in
the future less than 28 days, the leap warning bits are set.
On Wed, May 13, 2015 at 11:44:37AM +0200, Marco Marongiu wrote:
I understand that the leap second is not armed in the kernel if only the
warning is set. Rather, it seems that the warning is used by a client to
understand if it should believe its upstreams when they claim there will
be a leap
Hi there
In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in
the future less than 28 days, the leap warning bits are set.
What are the practical consequences of the warning bits being set? Will
they cause the leap second to be armed in the kernel eventually? What if
the kernel
On 12/05/15 11:28, Marco Marongiu wrote:
Hi there
In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in
the future less than 28 days, the leap warning bits are set.
What are the practical consequences of the warning bits being set? Will
they cause the leap second to be
On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote:
You might not need orphan mode at all - just the plain local refclock
driver.
You might also just need a customized leapseconds file.
Yeah, that was my first test — just:
server 127.127.1.1 minpoll 4 maxpoll 5
fudge
On Feb 23, 2015, at 6:38 PM, Ask Bjørn Hansen a...@develooper.com wrote:
On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote:
You might not need orphan mode at all - just the plain local refclock
driver.
You might also just need a customized leapseconds file.
Yeah, that
On 02/24/2015 01:23 AM, Ask Bjørn Hansen wrote:
I am trying to setup an ntpd to use the local clock as the reference
source and so I can set the time to late June and verify 1) what ntpd
does and 2) what clients do.
FYI, I researched the question of how to simulate an upcoming leap
second (as
Ask Bjørn Hansen wrote:
On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote:
You might not need orphan mode at all - just the plain local refclock
driver.
You might also just need a customized leapseconds file.
Yeah, that was my first test — just:
server 127.127.1.1 minpoll 4
Ask Bj?rn Hansen writes:
On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote:
You might not need orphan mode at all - just the plain local refclock
driver.
You might also just need a customized leapseconds file.
Yeah, that was my first test =E2=80=94 just:
server 127.127.1.1
Hi everyone,
I am trying to setup an ntpd to use the local clock as the reference source
and so I can set the time to late June and verify 1) what ntpd does and 2) what
clients do.
I had it working with the 4.2.4 that comes with FreeBSD 10.1 (and the local
clock), but I wanted to use 4.2.8
On 2015-02-23 17:23, Ask Bjørn Hansen wrote:
I am trying to setup an ntpd to use the local clock as the reference source
and so I can set the time to late June and verify 1) what ntpd does and 2) what clients
do.
I had it working with the 4.2.4 that comes with FreeBSD 10.1 (and the local
Martin might have a good answer for you.
I'd like to see these instructions written up.
You might not need orphan mode at all - just the plain local refclock
driver.
You might also just need a customized leapseconds file.
H
Ask Bj?rn Hansen writes:
Hi everyone,
I am trying to setup an
Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin
Le 16 janv. 2015 à 08:42, Harlan Stenn st...@ntp.org a écrit :
Terje Mathisen writes:
cmad...@cmadams.net (Chris Adams) wrote:
strange response!
Le 11 janv. 2015 à 21:18, Paul tik-...@bodosom.net a écrit :
Why do folks mention leap seconds on this list?
part of the NTP protocol deals with the scheduling insertion/deletion of leap
seconds.
Why do people point to leap-seconds.NTPtimestamp instead of just
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote:
Miroslav Lichvar wrote:
Here is a test showing error between two clients of a server
smearing.a large offset. With the cosine function you can see a large
spike when smearing started.
On 01/27/2015 10:16 AM, Terje Mathisen wrote:
Jochen Bern wrote:
Because they chose the long window (about one day) and made it exceed
the time an NTP peering needs to *act* on the perceived offset, yes. If
That's a a key feature of the long adjustment period: The smearing takes
so long
Jochen Bern wrote:
On 01/26/2015 01:03 PM, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number
Miroslav Lichvar wrote:
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote:
Miroslav Lichvar wrote:
Here is a test showing error between two clients of a server
smearing.a large offset. With the cosine function you can see a large
spike when smearing started.
Terje Mathisen terje.mathi...@tmsw.no writes:
The derivatives of sine/cosine are of course +/- cosine/sine, so they
stay smooth at all levels.
The point is that it is not smooth where it joins on to the regular
passage of time... It is possible to do this in an infinitely smooth
way, but using
David Malone wrote:
Terje Mathisen terje.mathi...@tmsw.no writes:
The derivatives of sine/cosine are of course +/- cosine/sine, so they
stay smooth at all levels.
The point is that it is not smooth where it joins on to the regular
passage of time... It is possible to do this in an infinitely
Jochen Bern wrote:
On 01/27/2015 10:16 AM, Terje Mathisen wrote:
Jochen Bern wrote:
Because they chose the long window (about one day) and made it exceed
the time an NTP peering needs to *act* on the perceived offset, yes. If
That's a a key feature of the long adjustment period: The smearing
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via NTP
Does that read there's *several* teams working on NTPv5 and not
communicating with each other right now ... ?
The ITU has just met in Geneva and discussed the
On 01/22/2015 07:04 PM, William Unruh wrote:
General relativity assures us that time exists and is measured by a
metric. Take that metric and define a proper time say at the center of
the earth.
(Bad choice because relativity says that clocks down the gravity well
run faster, but we've been
Terje Mathisen terje.mathi...@tmsw.no writes:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number of defined
Jochen Bern wrote:
Sorry for the delay, I'm *still* not back to my usual workplace ...
On 01/21/2015 11:39 AM, Mike Cook wrote:
I couldn’t find a definition of a monotonous function. Does it exist?
As David already suggested, I learnt my math in Germany - and switched
to CS before taking a
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a half
cosine to distribute the offset, which means that they have a time function
which is both continuous and monotonic, as well as having an infinite number
On 01/26/2015 01:03 PM, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number of defined
On 2015-01-26, Terje Mathisen terje.mathi...@tmsw.no wrote:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite number
On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote:
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via NTP
Does that read there's *several* teams working on NTPv5 and not
communicating with each other right now
On 2015-01-26, William Unruh un...@invalid.ca wrote:
On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote:
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via NTP
Does that read there's *several* teams working on
On 26/01/15 17:11, William Unruh wrote:
physical principle ( the frequency of oscillation of a cesium atom in a
XX
certain transition) and the rotation of the earth. It used to be defined
^not
It's a quantum
David Malone wrote:
Terje Mathisen terje.mathi...@tmsw.no writes:
One of the good points about Google's smear is the fact that they use a
half cosine to distribute the offset, which means that they have a time
function which is both continuous and monotonic, as well as having an
infinite
Miroslav Lichvar wrote:
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote:
One of the good points about Google's smear is the fact that they use a half
cosine to distribute the offset, which means that they have a time function
which is both continuous and monotonic, as well as
On 2015-01-26, David Woolley david@ex.djwhome.demon.invalid wrote:
On 26/01/15 17:11, William Unruh wrote:
physical principle ( the frequency of oscillation of a cesium atom in a
XX
certain transition) and the rotation of the earth. It used
I'm expecting that NTPv5 will include things like the timescale used by
the timestamp, so as long as the systems agree on how to convert
timescales if they are not the same between the client and server
(hello, General Timestamp API) it will be OK if an NTPv4 or NTPv5 box
talks to an NTPv5 box, as
Jochen Bern writes:
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote:
The US will soon be considering a means for dissemination of delta T via =
NTP
Does that read there's *several* teams working on NTPv5 and not
communicating with each other right now ... ?
Nobody has talked to me,
Sorry for the delay, I'm *still* not back to my usual workplace ...
On 01/21/2015 11:39 AM, Mike Cook wrote:
I couldn’t find a definition of a monotonous function. Does it exist?
As David already suggested, I learnt my math in Germany - and switched
to CS before taking a shot at a PhD, which
Anyone wanting to check whether they are being fed spurious leap-second
information may like to try my Leap Trace program, available as a
Windows GUI and command-line program, and as a Perl script for other OS.
http://www.satsignal.eu/software/net.htm#NTPLeapTrace
--
Cheers,
David
Web:
On Friday, January 23, 2015 at 3:55:02 AM UTC-5, Marco Marongiu wrote:
On 21/01/15 15:31, Mike S wrote:
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering
On 1/23/2015 2:03 PM, schmidt.r...@gmail.com wrote:
What shall you program
about the end of June, 2016, or December, 2020? What will be the
interval of time between now and then?
Depends. What are you doing which requires 1 second accuracy a year or 5
from now? Does it need to happen at a
William Unruh un...@invalid.ca writes:
General relativity assures us that time exists and is measured by a
metric. Take that metric and define a proper time say at the center of
the earth. Now one can ask whether TAI or UTC is a function of that
time.
As Mike points out, you've subtracted
On 21/01/15 15:31, Mike S wrote:
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering practices.
That's right. Instead of recognizing that the world rotates on it's
On 21/01/15 10:39, Mike Cook wrote:
I couldn’t find a definition of a monotonous function.
It's an obvious mis-choice of words by someone whose name suggests they
aren't native English speaker. It clearly is intended to mean
monotonic. See
William Unruh un...@invalid.ca writes:
Note UTC differs from TAI by an interger number of seconds, AND that
integer changes with the leap second. Ie, it cannot be continuous if TAI
is continuous.
That assumes that UTC can be represented as a real number with the
standard topology, which doesn't
Mike S schrieb:
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering practices.
That's right. Instead of recognizing that the world rotates on it's own,
they want to
On 1/22/2015 1:04 PM, William Unruh wrote:
General relativity assures us that time exists and is measured by a
metric...
still 1 second different in the two scales. And for Jun 30
23:59:59.9 and Jul 1 00:00:00.1
while TAI says that difference is .2 sec, UTC says it is
Mike S writes:
Both TAI and UTC are continuous, and could in a non-standard way, be
represented by real numbers (Time, below), where they wouldn't differ.
TAI and UTC only differ in how they're labelled, as you say. It's
POSIX which isn't monotonic or continuous, it repeats leap seconds.
On 2015-01-22 11:04, William Unruh wrote:
On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote:
William Unruh un...@invalid.ca writes:
Note UTC differs from TAI by an interger number of seconds, AND that
integer changes with the leap second. Ie, it cannot be continuous if TAI
is
On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote:
William Unruh un...@invalid.ca writes:
Note UTC differs from TAI by an interger number of seconds, AND that
integer changes with the leap second. Ie, it cannot be continuous if TAI
is continuous.
That assumes that UTC can be
On 1/22/2015 5:45 AM, David Malone wrote:
That assumes that UTC can be represented as a real number with the
standard topology, which doesn't seem to be what TF.460 says. It
describes each second as labelled, which means that you have to
stitch together all possible unit intervals for each
On 1/21/2015 2:10 AM, Mike Cook wrote:
And one of the reasons why a significant portion of the computing
community wants to get rid of leap seconds. A coverup for bad
engineering practices.
That's right. Instead of recognizing that the world rotates on it's own,
they want to change reality so
Jochen Bern wrote:
On 01/19/2015 08:42 AM, William Unruh wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
[...]
You two *both* need to get your terminology (and its definitions) right.
[...]
Wow, IMO this is *very* good summary of the problem, and explanation of
the reasons for
Programmers universally compute the number of days between two dates by
determining the seconds of the two dates (by using a function such as
getTimeInMillis() for each date), computing the difference in seconds
between the two dates, and dividing the difference by 86,400.
I proved this to myself
On 01/20/2015 10:58 AM, Martin Burnicki wrote:
Wow, IMO this is *very* good summary of the problem, and explanation of
the reasons for it.
Thanks, but after pondering the topic another night, I found my treatise
to still be faulty. :-} Let me try to amend:
---
The smaller point
On 1/20/2015 6:14 PM, Jochen Bern wrote:
So, what*function* might people be thinking of when they assert those
properties to apply (or not) to timescales?
TAI = UTC(x) and UTC = TAI(x). And that's part of the problem.
There seems to be the thought that if you do that across a leap second,
Le 21 janv. 2015 à 07:18, Terje Mathisen terje.mathi...@tmsw.no a écrit :
Mike S wrote:
The real problem is systems (POSIX, particularly), which incorrectly
handle time, despite having over 40 years to get it right. They try to
please everyone, while pleasing no one. POSIX tracks and does
Mike S wrote:
The real problem is systems (POSIX, particularly), which incorrectly
handle time, despite having over 40 years to get it right. They try to
please everyone, while pleasing no one. POSIX tracks and does
calculations on determinate intervals (seconds since 1/1/1970, and every
minute
Harlan Stenn wrote:
Martin,
If a fix is found for this in time I'll get it in 4.2.8p1.
I'm working on this with Juergen, and I hope we get this done.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
___
questions mailing list
Marco Marongiu wrote:
On Linux it worked correctly... That is?
Yes. My first tests were more focused on Windows in different versions,
and I used just another Linux box with a simple setup (just NTP client,
no leap second file) to compare the results against those from windows.
I'm going
On 19/01/15 09:25, Martin Burnicki wrote:
Marco Marongiu wrote:
On Linux it worked correctly... That is?
Yes. My first tests were more focused on Windows in different versions,
and I used just another Linux box with a simple setup (just NTP client,
no leap second file) to compare the
On 2015-01-19, Mike S mi...@flatsurface.com 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
I AM clearly
William Unruh un...@invalid.ca wrote:
On 2015-01-19, Mike S mi...@flatsurface.com 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
On 19/01/15 12:15, Mike S wrote:
You clearly misunderstood TF.460, because you still have it wrong. There
is no discontinuity, the two scales merely count time differently. This
is how the time of the next leap second will be enumerated in each:
You are relying on an appendix that deals with
[And this is why I wonder why leap seconds are discussed here.]
On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote:
You clearly misunderstood TF.460
You're using the wrong reference. Try this one from 2007:
On 19/01/15 14:47, Martin Burnicki wrote:
Actually I've tested a 4.2.8 client on Linux which only receives the
leap second warning from an upstream NTP server.
There are other configuration options like presence of a leapsecond
file, NTP server mode receiving the announcement from a
On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote:
You're citing a internal letter, from one BIPM group to another, asking
them to bring something before the ITU. It's not normative, it's not
informational, it's just correspondence.
That doesn't make any sense. When the
On 1/19/2015 8:05 AM, David Woolley wrote:
You are relying on an appendix that deals with representation of dates.
The main part of the standard is worded in terms of their being missing
seconds.
How proving that you're unable to provide a quote to back up what is,
quite simply, a blatant
On 1/19/2015 10:22 AM, Paul wrote:
On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote:
You're citing a internal letter, from one BIPM group to another, asking
them to bring something before the ITU. It's not normative, it's not
informational, it's just correspondence.
That
On 1/19/2015 9:04 AM, Paul wrote:
[And this is why I wonder why leap seconds are discussed here.]
On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote:
You clearly misunderstood TF.460
You're using the wrong reference.
Huh? You plainly don't understand the relationships or
On 1/19/2015 2:42 AM, William Unruh wrote:
I quoted from the document you yourself pointed me at. TAI is
continuous. UTC differes from TAI by and interger number of seconds, and
that integer changes when a leap second occurs. If x is continous x-n
where n changes at some time, is NOT
William Unruh un...@invalid.ca wrote:
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote:
William Unruh un...@invalid.ca wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 86400 seconds per year.
You clearly don't understand
On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com wrote:
Again, you need to up your understanding of standards terminology.
No, if you're going to use jargon you should provide the meanings you're
using. Since you clearly have your own version of reality it will help the
rest of
On 1/19/2015 11:58 AM, Paul wrote:
On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com
mailto:mi...@flatsurface.com wrote:
Again, you need to up your understanding of standards terminology.
No, if you're going to use jargon you should provide the meanings you're
using. Since
On 1/19/2015 11:56 AM, William Unruh wrote:
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote:
I am not sure what you mean by sees, but I cant figure a meaning
that would be compatible with the fact that UTC clearly identifies
86401 seconds on the day the leap second occurs.
If you ask utc how
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote:
William Unruh un...@invalid.ca wrote:
On 2015-01-19, Mike S mi...@flatsurface.com 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
On 01/19/2015 08:42 AM, William Unruh wrote:
On 2015-01-19, Mike S mi...@flatsurface.com wrote:
On 1/18/2015 6:04 PM, William Unruh wrote:
UTC always has 31536000 seconds per year.
You clearly don't understand how leap seconds work. You're embarrassing
yourself now. When there's a leap
On 2015-01-18 16:04, William Unruh wrote:
UTC always has 86400 seconds per year.
ITYM POSIX time always has 86.4ks/day - by that definition POSIX keeps
legal civil time using mean solar seconds, not SI seconds or leap seconds.
Any correspondence between POSIX time, SI seconds, UTC, or TAI, is
On 2015-01-18, Mike S mi...@flatsurface.com 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
On 2015-01-18, Mike S mi...@flatsurface.com 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
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
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
1 - 100 of 308 matches
Mail list logo
