I was just sent a nice TBolt / Heather.exe screenshot from alert time-nuts reader Steven Reyer showing "LEAP PENDING!".
The good news is that, yes, there will be another leap second (in June). The bad news is that, no, there is not a leap second at the end of this month (January) nor at the end of March for that matter. So depending on how you interpret "pending", Heather.exe has a bug. This sort of premature or ambiguous leap second reporting has caused problems with users in the past, especially when the leap second is announced more than 3 months ahead. Note that this is not a GPS problem, nor a Trimble problem. It's just a problem with user written software. In this case the "user software" is Heather. This message is derived from Trimble's 0x8F-AC Supplemental Timing Packet, minor alarm, bit 7. Note that the bit does not necessarily imply there is a leap second at the end of *this* month. All it means is a leap second is pending at the end of *some* month in the future. The user is then suppose to use packet 0x58 UTC Data (Type 5) to decode WN_lsf, DN_lsf, delta_lsf in order to figure out which month it is and report that. Like most GPS timing receivers, the TBolt handles leap seconds correctly when they occur. So no worries. But if you write your own add-on software and dare to report leap seconds ahead of time, you must do the math yourself. Give Mark Sims (author of Heather) first chance to fix it; if he doesn't want to then one of you can be a hero and send him a fix to him. For extra confidence you can use packet 0x8E-A4 to test your code. /tvb _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
