Interesting Leap Second Information

This came from Lou Estey from UNAVCO:

This week's tip: leap seconds

Yes, there was another positive leap second inserted into UTC at the end of the last minute of 31 Dec 2016.
This makes a total of 18 positive leap seconds (and zero negative leap seconds) inserted into UTC since
the beginning of GPS time, which started at 6.0 Jan 1980, although the first leap second insertion into
UTC was done at the end of the last minute of 30 June 1972. (In fact, so far, 1972 holds the distinction
of being the only year with two leap second insertions, since another was inserted at the end of the last
minute of 31 Dec 1972.)

Leap seconds are inserted into UTC to keep UTC within (plus or minus) 0.9 seconds of UT1, where UT1 is UT0
corrected for the Earth's polar motion in a sidereal frame and where UT0 is the Universal Time base defined
as precise solar time at the zero meridian -- or just think of UT1 a time based on the actual rotation of
the Earth. By tracking UTC - UT1 over time, a decision is made when to adjust UTC by a whole second (the
leap second) to keep UTC within 0.9 second of UT1 with a target date insertion (so far) either at the end
of the upcoming June or the end of the upcoming December, so that the last minute of those leap second
insertion months will have 61 seconds. The decision of when to adjust UTC is usually made about three or
four months prior to the insertion date (so, let's say, by late March/early April for an upcoming June
insertion or by late September/early October for an upcoming December insertion). Since 1972, those whole
second adjustments have required only positive leap seconds, therefore adding (or inserting) seconds into UTC.

Undoubtedly most of you also read or heard, either this time or for a leap second in past years, that leap
seconds are necessary due to the slowing rotation of the Earth, or a longer Earth-day as time goes on.
That's correct, but the details are more involved than what that statement implies at first glance.

Yes, the Earth's rotation is slowing (and has been slowing for the entire history of the Earth, or at least
since the Moon has been around which is now known to be for at least 4.51 billion years) and currently this
slowing of the rotation results in an increase in the length of a mean solar day of a couple of milliseconds
every century. (This is about 2.3 milliseconds/century based on laser ranging from the optical corner-cube
reflectors left on the Moon by Apollo astronauts and from another on Lunokhod 2. NASA's Goddard Space Flight
Center has this nice little exercise: https://spacemath.gsfc.nasa.gov/earth/6Page58.pdf
where you get to figure out the increase in the length of a mean solar for about the last 0.9 billion years
based on fossil coral and other fossil data, with the surprising result of a long-term mean solar day
lengthening of 2.4 milliseconds/century -- very close to the current value -- although you can plainly see
that the lengthening is not constant through the geologic epochs, just as it is not a constant over shorter
periods of time.)

The reason for so many leap seconds being needed to be inserted into UTC since 1972 is due to the SI definition
of the second made in 1967, that being "the duration of 9,192,631,770 periods of the radiation corresponding
to the transition between the two hyperfine levels of the ground state of the cesium 133 atom" -- something
based on quantum physics and reproducible anywhere, any time, and in an reference frame (given the necessary
equipment and a bit of cesium-133). The idea was to replace the astronomical definition, which had been 1/86,400
of the mean solar day, although even that was replaced with an definition of 1/31,556,925.9747-th of a tropical
year -- and here's the point -- this was based on the length of mean solar day in 1900. In other words, in 1967
the mean solar day was already about 0.67 x 2.3 milliseconds longer than the mean solar day in 1900, and the SI
second was defined to be very close -- to about 0.1 parts in 1e9 -- to the 1900 value. So by doing this, we had
already, right at the start in 1967, based UTC on a 'short' second that would drift from the actual rotation
of the Earth (i.e. UT1) by 1 second approximately every 650 (= 1/(0.67x2.3e-3)) days, or about every 1 and 3/4 years,
which, very roughly speaking, is about how often we have to deal with a leap second to keep UTC and UT1 in sync.

Now, _if_ back in 1967 someone had said, "Hey, hold on a second --" (pun intended) "-- the length of mean solar
days are going to keep getting longer. Let's be proactive and define a 'long' second to keep our notion of UTC
and the Earth's rotation in sync for at least a few decades ..." and if the SI definition of the second had
been to set the number of cesium-133 hyperfine periods to be larger by 20-30 parts per 1e9 (say, around
9,192,631,997 periods), then since 1972 we would have had only needed a handful of leap seconds, with about half
of them being positive and the others being negative. But, even if that had been done, the gradual lengthening
of the mean solar days would caught up and overtake this 'long' second definition for this hypothetical UTC
and we eventually would have been in the sane situation we are now.

Ok, what do leap seconds have to do with teqc? For GPS data, they really aren't important at all -- as long as
one does not need to convert GPS time into UTC. This is because GPS time always has exactly 604800 seconds in
every GPS week, or in other words, leap seconds do not effect GPS time. (The same is true for Galileo time,
Beidou time, QZSS time, and IRNSS time.)

However, for GLONASS, leap seconds are very important. This is because GLONASS time is based on UTC(SU) ... or
think Moscow standard time if you are not familiar with UTC(SU). For example, in a RINEX file the epoch of a
GLONASS ephemeris is in UTC, i.e. from https://igscb.jpl.nasa.gov/igscb/data/format/rinex211.txt

| TABLE A11 |
| GLONASS NAVIGATION MESSAGE FILE - DATA RECORD DESCRIPTION |
+--------------------+------------------------------------------+------------+
| OBS. RECORD | DESCRIPTION | FORMAT |
+--------------------+------------------------------------------+------------+
|PRN / EPOCH / SV CLK| - Satellite number: | I2, |
| | Slot number in sat. constellation | |
| | - Epoch of ephemerides (UTC) | |
| | - year (2 digits, padded with 0, | 1X,I2.2, |
| | if necessary) | |
| | - month,day,hour,minute, | 4(1X,I2), |
| | - second | F5.1, |

(Here, UTC means normal UTC, not UTC(SU), so UTC(SU) has to be adjusted by an additional 3 hours to get UTC.)
So if one is not properly keeping track of leap seconds, then GLONASS ephemeris dates in RINEX end up being
wrong by some number of whole seconds: for every positive leap second missed, the second value in a RINEX
ephemeris date will be too large by +1.

There is an additional complication for GLONASS pseudoranges in some formats (e.g. some Ashtech formats)
that the correct number of leap seconds at the time of the observation needs to be known in order to reconstruct
the correct value for the pseudoranges to GLONASS SVs. For these formats, the wrong leap second value
leads to very strange pseudoranges for the GLONASS SVs.

Now, inside of teqc there is a C function (or think a table) of when to insert how many leap seconds for a
given date and time. Because each new leap second insertion is not established earlier than the three- to
four-month lead time mentioned at the beginning of this tip, this function cannot be updated until then for
each new leap second. This means that I have to monitor what NIST or USNO is finding for the difference
between UTC and UT1 and keep an eye on whether "the powers that be" have decided to insert a leap second
into UTC in the coming months. If so -- ALERT! -- there will definitely be a new version of teqc released
prior to that leap second insertion so that handling of GLONASS will (hopefully) continue to be correct.

What happens if you decide _not_ to use an updated teqc prior to a leap second insertion? Well, all will be
well up until the actual leap second insertion point. After that, all non-GLONASS data should be correct.
But for GLONASS, things will get messed up quickly because teqc will be using an out-of-date table, i.e. one
that's missing at least that last leap second. You'll really need to use an updated teqc to keep functioning
with GLONASS without special teqc options.

The backdoor special option trick, however, is to use either the '-O.leap' and/or '-N.leap' options with the
correct leap second value (number of leap seconds since the beginning of GPS time, 6.0 Jan 1980) -- for data
with GLONASS after the leap second insertion. With these, you should -- hopefully -- be able to limp along
until you make the transition to the updated teqc.

Happy teqc-ing!

cheers,
--lou

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Louis H. Estey, Ph.D. office: [+001] 303-381-7456
UNAVCO, 6350 Nautilus Drive FAX: [+001] 303-381-7451
Boulder, CO 80301-5554 e-mail: lou unavco.org
WWW: http://www.unavco.org http://jules.unavco.org

"If the universe is the answer, what is the question?"
-- Leon Lederman