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

Tom Van Baak tvb at LeapSecond.com
Wed Jul 20 03:25:59 EDT 2016


Hi Gary,

> 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.

Sounds correct. The point is to never to hardcode a "preference". You code against a spec. And the spec is simple:

"A positive or negative leap-second should be the last second of a UTC month"

It would appear that assuming the preference was actually a rule is what causes the Z3801A f/w to mis-report the next leap second as September instead of December. Back in the late 90's, when the 58503/Z3801 code was written, this made sense. Leap second annoucenements were not made half a year in advance back then.

/tvb

----- Original Message ----- 
From: "Gary E. Miller" <gem at rellim.com>
To: "Tom Van Baak" <tvb at LeapSecond.com>
Cc: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
Sent: Tuesday, July 19, 2016 10:36 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

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...

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

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
 gem at rellim.com  Tel:+1 541 382 8588



More information about the time-nuts mailing list