[LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
sla at ucolick.org
Tue Jan 15 23:54:34 EST 2019
On Tue 2019-01-15T15:18:00-0800 jimlux hath writ:
> It would be much easier for the operators if they could just *enter* the UTC
> time, and have the software calculate the GPS Week:millisecond (or vice
The 1970 CCIR decision to begin having leap seconds was made without
any technical docuements about how to implement them. At a public
meeting after the CCIR decision and prior to 1972 one of the delegates
to the ongoing CCIR working group meetings was asked if he could
talk about the details "unless that is sub judice".
In the context that was a jab from someone who was not happy with the
decision for leap seconds. But everyone was going to have to be using
the new broadcast time scheme, so it was not funny then to be joking
about technical details of the system being secret. That became even
less funny over the decades.
More disturbing were the contributions to the 1972 CCDS meeting where
one of the technical delegates to the CCIR process wrote
It is clear that the recommendation of the CCIR concering the UTC
system is limited to "standard frequency and time-signal
transmissions" in the sense of Study Group 7 of the CCIR.
This recommendation does not concern other programs and other
methods of broadcasting time, such as radio or television
announcments of the hour, hourly services for maritime or air
navigation, public clocks, etc.
Again, UTC is a way of providing AT and UT in the same broadcast.
The CCIR feels responsible for transmitting AT and UT to users in
a reliable fashion and with appropriate technical means.
It does not matter to the CCIR that users employ AT, UT, or UTC
for their particular problems. The responsibility of the CCIR
ends with the transmission of UTC by the specified stations.
Another delegate both to the CCIR and that CCDS meeting wrote
We should limit ourselves to discussing this issue with people who
are well aware of the problems involved.
Those are basically the folks who made the CCIR decision saying
Many folks don't have to use this, especially us.
Blame the victim if they don't use the right thing.
Let's not talk about this.
So the result was that the technical folks did not talk about leap
seconds. Nobody was ever tasked with setting up a scheme for
transmitting information about leap seconds that was more automated
and reliable than the BIH giving letters to the post office to send to
various national time service agencies.
But before the technical folks washed their hands they arranged for
various international assemblies to produce statements approving of
the leap seconds. Subsequently the bureaucratic folks took those
statements to other national and international bodies and achieved
approval for UTC with leap seconds in arenas where the original
technical folks had admitted they might not be the best strategy.
At this point in history it is unclear who of these technical folks
believed that the CCIR decision had limited scope and who were being
shrewdly tacit about their ongoing goals for international approval.
The only internationally official clue that UTC might not be the best
tool was CCIR recommendation 485
which allowed that TAI might be preferable to UTC for some purposes.
This rec was withdrawn in 1997. That was just before the "leap
seconds must die" process began in earnest in 1999.
Ironically at the 14th CCTF meeting in 1999 the head of the BIPM
opined that anyone who did not like leap seconds should use TAI as
given in rec 485. This betrays that not even the head of BIPM, who
define TAI, was aware that the ITU had withdrawn that rec two years
As Captain said in Cool Hand Luke
Whut we've got heyah is failya tuh c'municate.
Steve Allen <sla at ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
More information about the LEAPSECS