On Tue, 5 May 2015 22:54:03 -0700, Steve Allen wrote:
Like the TymServe 2100 units there will probably be other systems that
fail because of a lack of leap seconds. That means that 45 years ago
the CCIR put us all into a Catch-22 situation, and the ITU-R inherits
the undesired responsibility
On May 5, 2015, at 8:37 PM, Warner Losh i...@bsdimp.com wrote:
It is time to look at other solutions to the synchronization problem that can
be implemented correctly.
By all means. That is not what the ITU has been doing. Redefining UTC to
cease leap seconds is the opposite of a solution.
On May 5, 2015, at 9:19 PM, Rob Seaman sea...@noao.edu wrote:
On May 5, 2015, at 6:16 PM, Warner Losh i...@bsdimp.com wrote:
This is an excellent example of the unintended consequences of leap seconds,
and the ways they insinuate themselves into non-obvious parts of the code.
...and is
On May 5, 2015, at 6:16 PM, Warner Losh i...@bsdimp.com wrote:
This is an excellent example of the unintended consequences of leap seconds,
and the ways they insinuate themselves into non-obvious parts of the code.
...and is it somehow impossible that there might be unintended consequences
On May 5, 2015, at 7:02 PM, Tom Van Baak t...@leapsecond.com wrote:
As seen at
http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
and also as experienced at Keck Observatory last night, some models
of GPS time servers just did their firmware's W1K rollover, so those
are saying
As seen at
http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
and also as experienced at Keck Observatory last night, some models
of GPS time servers just did their firmware's W1K rollover, so those
are saying the date is 1995-09-17.
But the leap second is, inappropriately,
Like the TymServe 2100 units there will probably be other systems that
fail because of a lack of leap seconds. That means that 45 years ago
the CCIR put us all into a Catch-22 situation, and the ITU-R inherits
the undesired responsibility of doing or not doing something about it.
On Tue
Hi Tom,
Tom Van Baak wrote:
As seen at
http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
and also as experienced at Keck Observatory last night, some models
of GPS time servers just did their firmware's W1K rollover, so those
are saying the date is 1995-09-17.
But the leap second is,
ensemble of
programmers who only heard of GMT.
From: Tom Van Baak t...@leapsecond.com
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Monday, May 4, 2015 7:40 PM
Subject: Re: [LEAPSECS] W1K GPS rollover for some time servers
As seen at
http://lists.ntp.org/pipermail
On May 3, 2015, at 5:52 PM, Steve Allen s...@ucolick.org wrote:
As seen at
http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
and also as experienced at Keck Observatory last night, some models
of GPS time servers just did their firmware's W1K rollover, so those
are saying the
As seen at
http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
and also as experienced at Keck Observatory last night, some models
of GPS time servers just did their firmware's W1K rollover, so those
are saying the date is 1995-09-17.
But the leap second is, inappropriately,
As seen at
http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
and also as experienced at Keck Observatory last night, some models
of GPS time servers just did their firmware's W1K rollover, so those
are saying the date is 1995-09-17.
But the leap second is, inappropriately, getting the
On Mon 2015-05-04T02:01:15 +, Alex Currant via LEAPSECS hath writ:
The point is that any complication is a potential source of
programming errors, and any potential source will eventually lead to
problems in predictable and unpredictable ways. The W1K problem is
one example. Leap seconds
13 matches
Mail list logo
