[LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

[Tom Van Baak]

> The data format only has a "leap second pending flag", which means a
> leap second is to be inserted.

Hi Martin,

Ouch. Well that's a problem. LSEM aside, what are you going to do if the earth continues to gradually speed up as it has the past couple of decades?

If you look at the WWVB spec, it also has a single bit for leap second pending. So at first glance it would appear to have the same problem as DCF77. But WWVB has bits for DUT1; the sign bit of DUT1 effectively tells you if the pending leap second is insert or delete.

/tvb

----- Original Message ----- 
From: "Martin Burnicki" <martin.burnicki at burnicki.net>
To: "Tom Van Baak" <tvb at leapsecond.com>; "Leap Second Discussion List" <leapsecs at leapsecond.com>; "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
Sent: Friday, July 22, 2016 1:44 AM
Subject: Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year


> Tom Van Baak wrote:
>> Time to mention this again...
>> 
>> If we adopted the LSEM (Leap Second Every Month) model then none of
>> this would be a problem. The idea is not to decide *if* there will be
>> leap second, but to force every month to have a leap second. The IERS
>> decision is then what the *sign* of the leap second should be this
>> month.
> 
> Although this approach sound good, it would cause major problems for
> users of the German longwave transmitter DCF-77. The data format only
> has a "leap second pending flag", which means a leap second is to be
> inserted. AFAIK there is no spec to announce a negative leap second via
> DCF-77.
> 
> Martin
>