[time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Magnus Danielson magnus at rubidium.dyndns.org
Wed Jul 20 06:58:44 UTC 2016


Gary,

On 07/20/2016 07:36 AM, Gary E. Miller wrote:
> Yo Tom!
>
>>> IERS is free to schedule a leap second at the end of any month. And
>>> it may be an insert or a delete. Assume nothing more or less in your
>>> code. Code and test and document for positive and negative leap
>>> seconds equally.
>>
>> Got a reference for that?  I know many people that will insist
>> otherwise.
>
> Never mind, I think I found a reference that is commonly quoted:
>
> CCIR Recommendation 460-4 (1986).
>
> http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
>
>     2.	Leap-seconds
>     2.1 A positive or negative leap-second should be the last second
>     of a UTC month, but first preference should be given to the end of
>     December and June, and second preference to the end of March and
>     September.
>
> But it is marked Superceded.  I'm guessing that is replaced by 460-6?
>
> http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en
>
> It says the same thing in section 2.1
>
> Nothing says it has to be those 4 months...

No, but the wording do say that those four month is preferred. For those 
that is curious:
http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf

8<---
2     	Leap-seconds

2.1	A positive or negative leap-second should be the last second of a 
UTC month, but first preference should be given to the end of December 
and June, and second preference to the end of March and September.

2.2	A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of 
the first day of the following month. In the case of a negative 
leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s 
of the first day of the following month (see Annex 3).

2.3	The IERS should decide upon and announce the introduction of a 
leap-second, such an announcement to be made at least eight weeks in 
advance.
--->8

Thus, any month can be scheduled, but there is a preference to end of 
half-year and then end of quarter. The main preference is used in 
practice, which is in good accordance with the rules, the Z3801A 
designers over-eagerly included also the remaining two end-of-quarter.

> I have some code comments in gpsd to fix...

Yes, but it can take a long time before it would bite you.
Beware of GPS-receivers such as Z3801A which now give the time of leap 
second 3 month to early, and beware that eventually end of March and end 
of September might become legal points even for a Z3801A.

Now, what annoys me is that the IERS message says that the leap second 
is scheduled for January:

8<---

                                               Paris, 6 July 2016

                                               Bulletin C 52

  To authorities responsible for the measurement and distribution of 
time


                                    UTC TIME STEP
                             on the 1st of January 2017


  A positive leap second will be introduced at the end of December 2016.
  The sequence of dates of the UTC second markers will be:		
		
                           2016 December 31, 23h 59m 59s
                           2016 December 31, 23h 59m 60s
                           2017 January   1,  0h  0m  0s
--->8

It is unfortunate that it says UTC TIME STEP on the 1st of January 2017, 
as it is scheduled for 31 December 2016.

This is a new habbit of IERS, and it is unfortunate and not helpful.
Older Bullentin C used the more correct reference to end of June or end 
of December.

Ah well.

Cheers,
Magnus



More information about the Time-nuts_lists.febo.com mailing list