I recorded the audio of the 3330 kHz signal of the National Research Council
of Canada's time signal station CHU from a few minutes before, until a couple
of minutes after, midnight UTC on New Years' Eve. A PDF of the annotated
sampled-signal time series between 23:59:00 and 0:00:01 can be found
On Jan 3, 2006, at 5:46 PM, Warner Losh wrote:
As someone who has fought the battles, I can tell you that a simple
table is 10x or 100x easier to implement than dealing with parsing
the data from N streams. Sure, it limits the lifetime of the
device, but a 20 year limit is very reasonable.
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: On Jan 3, 2006, at 5:46 PM, Warner Losh wrote:
:
: As someone who has fought the battles, I can tell you that a simple
: table is 10x or 100x easier to implement than dealing with parsing
: the data from N streams.
It is correct that DUT1 changes by +1.0 across a
positive leap second; going from a negative value
(e.g., -0.6) to a positive value (e.g., +0.4).
You would see the inverse in the case of a negative
leap second (DUT1 will, by definition, be positive
before the negative leap second and go negative
Those who have submitted data, plots, or descriptions of system response to
the leap second addition may want to forward those messages to ITU WP-7A.
Related to the Nov 2005 U.S. proposal to the ITU to redefine UTC and
abandon leap seconds, they are soliciting information from various sources
on
Rob Seaman scripsit:
Little support - and again, to a certain level of precision (easily
better than a second per day), all parties must certainly agree that
civil time (as we know it)
Why do you persist in claiming that all parties must certainly agree
on something that is precisely the
In message [EMAIL PROTECTED], Rob Seaman writes:
Hi Warner,
A more apt comparison would be to the leap year rules that we
have. We know the rules going
forward a thousand years or so.
Apt indeed. Leap seconds are scheduled at least six months in
advance. That's about one part in 15
In message [EMAIL PROTECTED], Tom Van Baak writes:
As for your Skyscan clock, I have several dozen
similar consumer RC clocks here and none has
ever adjusted itself for a leap second in real-time
The majority of such clocks only run the receiver for some part of
the day to save power.
One
The majority of such clocks only run the receiver for some part of
the day to save power.
One particular kind I examined ran the receiver until it had sync,
then powered the receiver down for 23 hours and repeated the cycle.
Yes, but the LS bit stays lit for the entire month (at
least for
A more apt comparison would be to the leap year rules that we
have. We know the rules going
forward a thousand years or so.
Apt indeed. Leap seconds are scheduled at least six months in
advance. That's about one part in 15 million. A thousand year
horizon for scheduling leap days is
With the surge of leap second captures this time
around, are there any concerns over the growing(?)
use of double :59 second or double :00 second
instead of :59:60 for a positive leap second?
Although not technically correct, they do seem a
practical, perhaps even clever, alternative -- in some
Ed Davies scripsit:
The main requirements for local civil time for the bulk of its
users are that:
Agreed.
1. local civil time matches apparent solar time roughly (e.g., the
sun is pretty high in the sky at 12:00 and it's dark at 00:00).
I think the last is the important point, or
In message [EMAIL PROTECTED], Rob Seaman writes:
I said:
all parties must certainly agree that civil time (as we know it) IS
mean solar time.
Ed says:
saying that it IS civil time is probably a bit strong.
Probably a bit strong is not precisely a staunch denial.
[...]
This is simply a
13 matches
Mail list logo
