Hi Warner,
Keeping cold spares is a good example. I can see that having to acquire GPS
lock and waiting up to 12.5 minutes for current leap second information would
be a problem. There must be a way to cache that state so rapid failover is
possible, in both the hot and cold spare case.
I know
But there have been real bugs due to leap indicators remaining set too
long, leading to bogus leaps at the end of July. So in practice there is
less risk in allowing leaps only in June and December.
Those real bugs are better fixed at their source than worked around in this
manner. Ok, easy
The truncated week numbers are a good source for potential errors
I agree, but...
If the current week number is off by more than +-127 then this is ambiguous.
No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and
there's no problem with that. In fact, in 2003
If the current week number is off by more than +-127 then this is
ambiguous. This has rolled over several time in the period where no leap
second had been scheduled for 7 years, and all the time the 8 bit week
number of the last recent leap second was broadcast.
Yes, see
As I said, the experiment has just started with DUT1 information.
Hi Rob,
I own dut1.org if you want to use that for a data service. For the past couple
of years it runs a script to return DUT1 values. I also would be willing to
give up leapsecond.org for the same purpose (right now it's just
Presumably a negative leap would be denoted ending :58?
Rob
That's a good question, one that most leap second tables (or leap second code,
for that matter) tend to ignore. Your :58 suggestion means his table is not
really a table of leap seconds anymore. Instead its a table of names of the
Who is right?
Demetrios has some nice data/plots. See especially page 8:
http://tycho.usno.navy.mil/papers/ts-2014/Matsakis-LeapSecondComments.URSI-2014.pdf
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
LOD variations are on the order of 200 ms (that's leap second every
week territory).
/tvb
- Original Message -
From: Tom Van Baak t...@leapsecond.com
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Tuesday, April 15, 2014 7:32 AM
Subject: Re: [LEAPSECS] Earth speeding up
If would really be good if there was one authoritative soure for this,
and that there was a uniform format. Ideally there would be multiple
ways to access it, via text and binary for different architectures. The
might be thought of as a UTC Metadata API, from which various UTC
Metadata
To be fair, and here I declare myself as an ex-member of the SOFA
board, the software is clearly labelled 2001-03-31 release. That
page is no longer even accessible from the SOFA home page where the
latest release is dated 2014-10-07.
Regards,
Mark Calabretta
Hi Mark,
I understand, but
Find a reliable source, and at the moment the most reliable source
is probably the IANA TimeZone Database
https://www.iana.org/time-zones
Steve,
Let me know if I'm using your most reliable source correctly:
- Go to https://www.iana.org/time-zones
- Read down until Latest version
- Download
I was googling for how to precisely set a sidereal pendulum clock to within 10
milliseconds of accuracy and was reminded of a topic I meant to bring up a
while ago.
The web is full of incorrect and outdated leap second information and tables.
Here's one example:
Standards of Fundamental
I seems Daniel is playing it safe. With DUT1 at only -0.46 s today and the
current rate of only -1.0 ms/day, he could have waited another 6 months or a
year.
Does anyone know what offset and rate threshold IERS uses to decide the next
leap second?
BTW, here's a record of previous DUT1 jumps:
if you are trying to measure UT1, it still takes time to correlate
the VLBI data and reduce it, and then send the results
to the right people, which doesn't happen without delay. (pardon
the pun). Synching up cesiums, hydrogen masers, and rubidium
fountains can happen much faster than it used
The best quip about the plot of LOD since 1972 is that the institution
of leap seconds must obviously have caused the earth to speed up.
Next time you visit IERS, ask for the special tour, and they will show you the
knob they use to adjust LOD ;-)
There was a clear local maximum of LOD
I'm not a geophysicist, but I too have noted what Tom reports. I've attached
a plot that by coincidence I just made last week.
The best hand-waiving arguments I've heard for these recent decadal
fluctuations
is that the oblateness of the Earth is changing, possibly due to the ice caps
Rob,
I think you mean many days shorter than 86400 seconds, not longer?
Right. Sign error. Thanks.
Any betting person would say the plot shows an upward trend over the past 40
years. A simple linear fit suggests the earth will be back to an honest 86400
second day within a few years,
The problem is that all applications should care about leap seconds.
It is a part of the time standard (UTC) that is papered over in POSIX time_t.
This is a false partitioning, and what causes the probelms.
Warner,
All applications should care? It's that going a bit too far? What, are you
Brooks,
Maybe I missed it way back in the thread, but can you give me an example why
you'd want a proleptic TAI or UTC?
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
This notion leaves open the question of the name UTC. In particular,
can the delegates to the ITU-R RA be persuaded to vote for a new
version of TF.460 if they are aware that the new wording will change
the legal definition of the word day in every country which has
adopted UTC as its time
The Multics clock design (a fixed bin (71), ie double word, representing
microseconds
since 00:00 01-01-1900) clearly informs the Unix one.
Was it 1900 or 1901? See:
http://www.multicians.org/jhs-clock.html
http://web.mit.edu/multics-history/source/Multics/ldd/bos/include/rdclock.incl.alm
Rob,
Glad you got a chance to read that volume. I thought Steve and I were the only
ones who spent time reading the history of atomic timescales over the last
century. It's really quite fascinating, if you have the time.
“Dr. STOYKO commented that even though the atomic standard is not a
That's disconcerting.
Brooks,
Nice that the list has come back to life. Looking back on your original
question about UTC documentation, you never mentioned what your actual
application is. I think it would be helpful if you could state what your
problem or your goal is. There are a lot of
I'm not sure how many of you are still interested in the early history of
atomic time and leap seconds. But I ran across a wonderful old article by Essen
on leap seconds, eventually found the magazine on eBay, and scanned it as part
of my primary sources collection.
To quote a friend: If UTC is time, and if UT1 is angle, then what is
(UT1-UTC)?
How can one subtract angle from time and have a meaningful result, without
both
being instantiations of the same concept?
No problem. If UT1 is angle, just divide by 2pi to get units of time. We do the
same
Too bad they don't explain the problem in any detail. Sure the root cause was
bad data from time.apple.com but it would be interesting, and educational, to
see how the dominoes fell in their massive infrastructure.
/tvb
- Original Message -
From: Steve Allen s...@ucolick.org
To: Leap
Would it be possible to fudge the longitude instead of the time?
That way automatic trackers that assume UTC is almost UT1 would still find
their target.
/tvb (iPhone4)
On Jun 8, 2012, at 11:48 AM, Rob Seaman sea...@noao.edu wrote:
Some other issues: pointing the telescope is not the same
Mike,
I'm not sure if you saw this earlier post:
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Wednesday, January 11, 2012 2:33 PM
Subject: Re: [LEAPSECS] pick your own length of second
Here's a plot that shows how a non leap second UTC would
look if the cesium resonance
I guess the ITU should get rid of leap years too then?
/tvb
- Original Message -
From: Steve Allen s...@ucolick.org
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Tuesday, April 03, 2012 2:01 PM
Subject: [LEAPSECS] Schlampig programmierte Software ist das Problem
If leap seconds were predictable (say they were exactly one every 18 months
for the next century) it would be perfectly practical to build an analogue
clock that had 61 divisions on the dial carrying the second hand, and which
jumped the 60 position in most minutes.
I would like to agree with
My analog clocks with just quartz crystals don't keep time to
within a second over the relevant interval. The ones with WWVB
receivers in them do a little dance every night when nobody is
watching and the signal is strong, and that dance looks a lot
like the handling of a leap second.
Yeah,
Both wrong. The right way is UTC-SLS.
Except it doesn't work for binary systems. 32.768 Hz watches
would prefer steps of 1/1024 s. UTS was a fine idea until it
was so overly specified. Since you are already dealing with
timekeepers that do not care so much about sub-second
accuracy a smoothed
How about making the second hand variable length. Have it
grow like Pinocchio's nose during a positive leap second.
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
There are two basic types of analogue clock display. One where the
second hand steps around the dial from second to second (thus
disawowing sub-second timekeeping), and the other where it moves
smoothly and continuously. It is interesting to contemplate how a
leap second would appear on each
The one-second dial could simply go around twice.
Which is what tv_nsec does...
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
I vigorously advocate only the general idea of rubberization. The
exact mode of rubberization is up to each individual implementor in
practice.
This sounds good to me too.
Alice and Bob may choose two different rubberization schemes, but the
magnitude of the difference between their clock
Try Tom's leapsecond.com, you can watch the next one in real time.
Only 161d 23h 23m 42s to go - tick, tick, tick,...
Yes, this is very impressive! I wonder whether
Tom Van Baak uses any C or Java or perl or..
functions to get current UTC.
Thanks!
Michael Deckers.
It's just
libc will need an updated table of leap-seconds to give you UTC,
and if you hand it a timestamp that is more than some set delta-T
from the last entry in the leapsecond table, it will return E2BIG
rather than give you a potentially wrong timestamp.
So I can't do operations on UTC time stamps
Try Tom's leapsecond.com, you can watch the next one in real time.
Only 161d 23h 23m 42s to go - tick, tick, tick,...
For those of you with a smart phone here's the mobile version:
http://leapsecond.com/m/nixie.htm
Note it's just JavaScript, not an app, so it works on any phone.
/tvb
But this was not at all the case in the 60's where countries or
labs would vary by tens or hundreds of microseconds or even
many milliseconds.
See: http://www.leapsecond.com/hpj/v17n12/v17n12p16.jpg
And: http://www.leapsecond.com/hpj/v19n4/v19n4p18.jpg
A huge part of UTC was the formation of
This email arrived a few minutes ago from a BIPM contact in Geneva.
/tvb
- Original Message -
From: @bipm.org
Sent: Thursday, January 19, 2012 9:10 AM
Subject: Re: ITU leap second announcement
Dear,
The discussion has concluded. The decision is to give the opportunity to those
Even now the many people who refer to UTC as a discontinuous
time scale, many of whom should be expected to know better, seem
not to be aware of it.
Mark Calabretta
Mark,
Welcome back to the list. It's been a while.
Here's a chance for some creative input. If as you say UTC
is not
Well I've always interpretted it as a co-ordinated form of UT. Steve Allens
next email implies others viewed it that way as well.
Stephen,
My reading of the original documents in the 60's is that the
co-ordinate was both astronomical-atomic and atomic-atomic.
I don't know how old you are,
They aren't moving anything. They are removing access to the Earth
orientation timescale.
Having failed to reach consensus, they should similarly fail to vote.
Rob Seaman
NOAO
Rob,
Get real. Do you really think access to the Earth orientation
timescale will be removed? Is this a hidden
Anyone specifically using such a tracking version of UTC
wants to track earth angle, rather than coordinate with civil
time, so why not just let them use UT1? That way they get
the best precision available, which is currently at the ones
or tens of microseconds level.
What these users want is a
I swear I typed SOPA. Something changed it before it went over the wire...
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Because access to UT1 requires frequent network access. I'm thinking
about atomic clocks that sit on a shelf for years, or which will be used
in isolated locations. We've discussed the use cases (for longer lead
time on leap seconds) in previous threads.
On network -- are there any earth
but I sure hope that astronomers wake up, stop complaining,
This is illogical (and borderline insulting). We're supposed to
wake up, but do so without talking about the issues?
Rob,
Yeah, sorry, that was a bit over the top.
I would like at some point, regardless of how the ITU vote turns
Ah, if name changes are allowed, then here's a solution:
Rename UTC to UTD
-- That's D for slightly drifting, the kind of timescale
that astronomers need, the one with leap seconds so
that it very closely follows UT1 but counts at an SI rate.
Take TAI minus 34 seconds and call it UTC
--
When was the _rate_ of UTC such that 86400s == 1 mean solar day?
ian
Ian,
Although on average LOD is more than 86400 s by a few milliseconds, in the past
fifty years about 3% of the days have been shorter than 86400 s. In the past
decade alone the figure is 14% (the earth has sped up quite
Another way of asking the question is 'what would the rate of leap seconds (or slope of TAI - UT or TT-UT)' if the
definition of a second gave is an average LOD - 86400s of more like 1ms or 100us. And would we have had to have
negative leap seconds...
Warner,
I'll track that down. I made
We can speculate contrary to fact on all sorts of things (those are the straw men of the subject line), but rather I
think this talking point is fairly neutral, or cuts both ways.
Rob
Right. Isn't it refreshing to have neutral points every now and then? Not everything about leap seconds is
I'm not in a position to put up a pick your own length of second and
replot cgi-bin page right this moment, but if there's interest I can
post my file of delta T values gleaned from tables in the Stephenson
and Morrison publications -- that goes to 1962. For after that my
plots just use C04 from
Here's a plot that shows how a non leap second UTC would
look if the cesium resonance were other than 9,192,631,770.
http://www.leapsecond.com/pages/ut/ut-ani-v2.gif
In retrospect it's too bad |DUT1| had to be so tight. If Essen
and friends had made it 10 s we wouldn't need leap seconds
in a
Earth orientation clocks and even-interval chronometers are simply two
different kinds of timekeepers.
Hi Rob,
That can be said for all clocks. Any object with periodic motion can
be made into a clock. Yes, some are bigger than others, some keep
better time than others, but no two are ever
I think this is because GPS is one of the systems which was designed
robustly with the notion that configuration changes are a routine part
of the operation, so a leap second is just another routine change.
It's not just GPS. In general any system today that already has an
automatic or manual
Another time war, far above the leap second level, but still interesting.
http://www.webmonkey.com/2011/10/html5-drops-the-time-element/
Details:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
BTW Windows has QueryPerformanceCounter(). However much as I like Unix
clock() and clock_gettime(CLOCK_MONOTONIC), I'm stuck with the problem
that there are many third party libraries with which I link and much
code written by other teams that I have no idea about.
Note that
consistent with contemporary records. A big problem for the subject
is that the agents responsible for UTC are very poor communicators.
Speaking of which, you and fellow astronomers are back from
your UTC conference. Is there any communication you can
share with us? Or will the forthcoming
If they were using stand-alone caesium clocks, then yes - gravity and
altitude would make big difference. But they locked their clocks to a
single common-view GPS satellite - surely, then, they were both
ticking at the same rate, and in sync?
Peter
Careful -- if they were using
And the clocks are not locked to a receiver, they are free but the offset
is continuously monitored through those CV measurement.
Would you not lock the GPS (GNSS) receivers to the CS-clocks being compared?
Björn
It's pretty common with high-performance timing to NOT lock the
local clock to
Well, it has been that way for ages, and it's the very
reason why UTC is defined as it is: to stay near UT
within a small margin.
Ah yes, but how large should the small margin be? And why?
If you read the old papers regarding time scales and UTC you
get a hint what of the major motivation was.
Eyeballing it says around a couple of milliseconds, which, unless
you have done things to your hardware, is lost in the NTP noise.
That was my conclusion too. It's one thing to work with hardware
at the micro- nano- or picosecond level. But the threshold with
PC's, even PC's running NTP, is so
Yea, the hard part is keeping that table up to date, but
I guess that's the job of a crontab entry not ntpd itself.
Warner,
Yes, a daily crontab entry would take care of it. Note the kernel
table really only needs two entries (today and tomorrow).
With two entries you have a full 24 hours in
This may or may not be a boundary condition. The fundamental
system engineering problem is that there are two different types
of time, two kinds of clock.
Rob,
You keep saying this, but there's only one kind of clock and
one kind of time. When you get two or more clocks you have
the ability
What is SOFA?
My google is as good as yours. Perhaps:
http://www.iausofa.org/sofa_ts_c.pdf
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
What they coyly omit is the duration of the window w (and the maximum slew
to the length of the second they apply in the middle of the window)!
I wrote them yesterday asking for details on w. If they reply you'll
be the first to know.
In a way part of the charm is that they didn't specify w.
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
It is not necessary, at least in the case of WWV and WWVB, to have special
equipment beyond a short wave radio to decode DUT1. It can be done by
ear.
In 1975 short-wave radios were common, but today a short-wave
radio qualifies as special equipment.
Even with a SW radio, when was the last time
Hi Tom,
I'd guess that any person or any system that needs DUT1 has long since switched over to telephone, fax, or the
internet to obtain this information.
I'd guess is not an inventory.
OK, you're welcome to poll your astronomical sources then and
see how many still get DUT1 from broadcast
Paul,
There are two separate issues here, accuracy and stability.
1) To make Earth more accurate and better match the SI second you need a
one-time increase in rotation rate. This rate correction is parts in ten to the
8th. Energy goes as the square of rate. See Earth energy here:
This hasn't even been fully correct during the times when UT1 was
observed with zenith telescopes (before about 1980). It is incorrect
today -- all the seven parameters of Earth orientation are of course
determined together, and UT0 is no longer needed nor used by anybody.
Are the
Hi Christopher,
Thanks for those interesting links.
Note PHK's original ACM article is:
http://queue.acm.org/detail.cfm?id=1967009
The recent IEEE mention is:
http://spectrum.ieee.org/podcast/at-work/innovation/does-anybody-really-know-what-time-it-is
With audio:
Note that the plotted frequency deviation is w.r.t. one value of the
US Frequency Standard, and other publications detail the changes which
were made to that frequency, so that is not necessarily close to the
present frequency of TAI.
You need to be careful with statements like this. Note the
And in Japan, since the main transmitter for JJY is within the
Fukushima evacuation zone, such watches have presumably been
freerunning and accumulating errors without resets ever since the
earthquake.
Fortunately (and uniquely) Japan has two time code transmitters;
the one in NE Japan at 40
Where can I buy one of those watches and how much will it cost me?
Right, only the very best quartz wristwatches are accurate enough
to expose leap seconds when they occur. I got my Pulsar PSR-10
for $125 on sale at Penny's many years ago. It's rated something
like 10 seconds a year (the 10 in
Two comments --
1) In my experience URL's change from time to time (note the U in
URI means Uniform, not Universal).
Whether compuserve or geocities, hp.com or sun.com, companies
and domains come and go; private or commercial or academic. It
just happens. You know this. Web layouts come and go
http://queue.acm.org/detail.cfm?id=1967009
Rob Seaman | Sat, 09 Apr 2011 18:57:17 UTC
It is simply fact that time-of-day and interval timekeeping are
two different things.
Rob,
Help me out here. That ACM generated time-stamp in your posting;
which is it by your definition: time-of-day or
Which special hardware is it that will allow a Unix machine to both tick SI seconds and accurately follow leap
seconds?
Special hardware? We don't need no stinkin' special hardware.
In the late 1970's when I first used UNIX it was called an on/off
switch.
When you turned on the PDP11 you set
Funny how we go around and around about this: is UTC
continuous or discontinuous? Well, it's continuous until it
isn't. It's a predictable offset, until it isn't. It's just plain old
24x60x60 mechanical gear sexagesimal notation, except
when it isn't.
We all know what UTC is, but struggle with a
- the civil day is the synodic day
Rob, please define is. Surely you don't mean equality, in a
mathematical sense. What really is meant by this statement?
You bring this topic up a lot. But everyone knows civil time is
now only grossly associated with anything solar; it doesn't match
at the
Since the velocity of the atomic clock causes relativistic dilation,
surely it is not the altitude-above-sea-level, but the radial distance
from the earths axis that we are talking about???
1)
This seems to be a common misunderstanding. Realize that
the relativistic dilation we're talking about
Doesn't it depend upon gravity (aka sea level)? Is that standardized?
Hal,
Yes and no.
The SI second is defined in the local reference frame. So your
cesium clock at sea level ticks SI seconds for you there. Your
cesium clock on a mountain ticks SI seconds for you there. The
fact that the
[ I'm posting this unsent email now that Warner independently
proposed the same thing! ]
In that is the nugget of how leap seconds are no different
announcements that the daylight/summer time zones transition will
happen at some date other than the previous schedule.
(e.g., due to some sports
Leap seconds differ from leap days only in their unpredictability.
Careful. Actually, you can go a lot more seconds of predictable
leap seconds than you can go days with predictable leap years
using the current 4/100/400 leap day rule.
The leap day error is, what, 365.2425 : 365.24219 = 850
The fundamental problem is that there is no formula for determining
when leap seconds occur.
True. You'll notice the continuous/discontinuous subject comes
up everytime someone new joins the list. Those words try to
convey an easy concept that all of us know well but no one can
quite say
However, it is a very distant horizon.
The issue here is one man's distant horizon is another man's
pending disaster and the list has shown there is no convincing
either side.
One way to think of it though, is in terms of the lifetime of the
technology involved. If your java class is expected
Steve,
See also Time Scales by Louis Essen for a whole set
of interesting historical nuggets on the origin of UTC:
http://www.leapsecond.com/history/1968-Metrologia-v4-n4-Essen.pdf
I would like to suggest that the rest of you read this as well.
In case you didn't already know, it was Essen
If this happens, I therefore think that there may end up being two
versions of UTC in common use, which would be a far worse situation
than today.
Stephen
Your java class going to provide the true TAI, the true UTC,
and the a user-friendly (smoothed, non leap second) version
of UTC, right? If
Your java class going to provide the true TAI, the true UTC,
and the a user-friendly (smoothed, non leap second) version
of UTC, right? If so, what name do you plan to use for that
latter time scale? Some OS's use words like system time
or gmtime.
I call it the UTC-SLS time-scale. See new
smoothing for that. (As I've said before, stopping leap seconds now
isn't helpful as it adds yet another mapping/complication, rather than
removing one)
This I don't understand. As far as UTC is concerned, isn't the
proposal to stop leap seconds effectively the same as IERS
just not sending out
@Warner, UTC-SLS is simply a clearly written way to reconcile UTC to
practical computing/business. I wish it was a recognised standard, but
it isn't. That places me in the position of making it a de facto
standard unless I receive a suitable alternative proposal. 8 million+
Java developers are
Yes, we've been here before. Here are some comments to
consider.
There are many forms of SLS; from those that spread the
leap across one second, or two seconds, or 30 seconds or
a minute, or an hour, or a day. Spread it across a year (or
however long it's been since the last leap second) and you
I've heard roughly the same story from another Murray Hill-ite. What
I find surprising about it is that most of the people involved in
Unics, later Unix, had worked on Multics. Multics, at least by the
1980s when I was using it, represented time as a FIXED BIN(71) (ie a
double-word
Oscillator),
or perhaps more practical, PDGPSDO.
/tvb
- Original Message -
From: Tom Van Baak t...@leapsecond.com
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Friday, January 14, 2011 10:01 PM
Subject: Re: [LEAPSECS] TAI adjustment ??
The process was even more
It would appear that making adjustments every 10 days is not
often enough, at least in the US, viz:
http://www.nist.gov/pml/div688/grp50/NISTUTC.cfm
http://www.nist.gov/pml/div688/grp50/nistusno.cfm
Even if we abandon the leap second, we have issues at the nanosecond level.
This is what
Alas, 'tis neither normal nor expected by the APIs and the programmers
who are implementing systems that deal with time.
Let me find some good references for you on how the UTC
paper clock actually works. Inter-comparing the clocks from
each national laboratory is in itself a fascinating
Given the question about leap seconds and WWVB, I ran
across some old NIST documents that shed light on the
evolution of broadcast time services.
Dated 1965,
NBS Low-Frequency Station WWVB to Broadcast International Unit of Time
http://tf.boulder.nist.gov/general/pdf/1721.pdf
This (and a
In case you didn't notice -- this year Christmas falls on the
beautiful looking MJD 5.
Some of the newcomers to the group may not be familiar
with MJD (Modified Julian Date). It's used extensively in the
timing community (see http://tycho.usno.navy.mil/mjd.html).
For those of you with
Do any sources of precise, accrued time have a leap second warning bit
as DCF 77 does?Is the philosophy of leap second warning in DCF 77 a
good paradigm for helping implement the leap second broadly?
WWV (short-wave, USA), WWVB (LF, USA), and JJY
(LF, Japan) all include leap second
101 - 200 of 216 matches
Mail list logo
