[time-nuts] June 30 2015 leap second

[Martin Burnicki]

d0ct0r wrote:
>
> Reading about "leap seconds" for the past two days, I found that common
> solution for it - just encode "leap second event" proactively and wait
> for it.
> Of course that possible only if device has that option. For example,
> BC637PCI has a menu item "7. Program Leap Event Seconds". Which I did.
>
> Now, if I do the request for time settings, its shows me following:
>
> Time Settings:
>
>   Mode                           : GPS
>   Time Format                    : Binary
>   Year                           : 2015
>   Local Offset                   : 0.0
>   Propagation Delay              : 0
>   Current Leap Seconds           : 16
>   Scheduled Leap Event Time      : 1435708799
>   Scheduled Leap Event Flag      : Insertion
>   GPS Time Format                : UTC Format
>   IEEE Daylight Savings Flag     : Enable
>
>
> "Scheduled Leap Event Time" - is so-called UNIX time. However, I am not
> sure where its take number "16" (Current Leap Seconds). Its definitely
> was not programmed there by me.

16 s is the current difference between GPS system time and UTC, which 
will increase to 17 after the next leap second. It is part of the UTC 
data set broadcasted by the satellites.

I'd expect that in a few days the GPS satellites start broadcasting the 
leap second announcement, and then yourGPS receiver should also find out 
by itself *when* the leap second will occur, and what the UTC offset 
will be thereafter.

When I looked this morning the sats did't broadcast this information, yet.

> Concerning of my clock project, I am thinking about best approach how to
> set up leap second procedure. I mean which time exactly I'll need to do
> correction for my clock (set time on RTC module). There is two options,
> I think. One: to reset RTC at July 1, 00:00:00 and set it back to June
> 30, 23:59:00. Or, at July 1, 00:00:01, set RTC back to July 1 00:00:00
> and then at July 1 00:00:01 reset RTC with occurrance of raising edge of
> 1PPS. I would prefer to play with July 1, because in this case I don't
> need to do much calculations to transfer RTC time to number of seconds,
> decrement it by 1 second, transfer it back to BCD format and write it
> back to RTC. Instead, I'll need just read/write RTC register which keeps
> number of seconds inside.

As said, once the sats start broadcasting this information your software 
should be able to read the time and leap second status from the PCI 
card, if the API supports this.

How you can handle this to set your clock depends on the capabilites of 
your clock, and its API.

Martin