[time-nuts] June 30 2015 leap second

d0ct0r time at patoka.org
Fri Jan 9 11:58:06 EST 2015

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


> Just because you observe one tz update from Debian does not imply that
> all "Linux systems" on planet earth (or in space) magically know about
> leap seconds. There must be millions (billions?) of embedded or
> isolated systems -- from web servers to desktops to military systems
> to gadgets to Raspberry Pi's to mobile phones, that have not, and will
> not ever receive this update.



More information about the time-nuts mailing list