Leap second: Difference between revisions

Revision as of 23:14, 17 April 2025

Revision as of 14:32, 29 April 2025

Line 296:

* Some older versions of Motorola Oncore VP, UT, GT, and M12 GPS receivers had a software bug that would cause a single timestamp to be off by a day if no leap second was scheduled for 256 weeks. On 28 November 2003, this happened. At midnight, the receivers with this firmware reported 29 November 2003, for one second and then reverted to 28 November 2003.<ref>{{cite web|url=http://www.leapsecond.com/notes/leapsec256.htm|title=256-Week Leap Second Bug|date=2 July 2013|url-status=live|archive-url=https://web.archive.org/web/20160304002759/http://www.leapsecond.com/notes/leapsec256.htm|archive-date=4 March 2016}}</ref><ref>{{cite web|url=http://compgroups.net/comp.protocols.time.ntp/motorola-oncore-receivers-and-leap-se/287130|title=Motorola Oncore receivers and Leap Second bug|date=2 July 2013|url-status=usurped|archive-url=https://web.archive.org/web/20130118233907/http://compgroups.net/comp.protocols.time.ntp/motorola-oncore-receivers-and-leap-se/287130|archive-date=18 January 2013}}</ref>

* Older Trimble GPS receivers had a software flaw that would insert a leap second immediately after the [[List of GPS satellites|GPS constellation]] started broadcasting the next leap second insertion time (some months in advance of the actual leap second), rather than waiting for the next leap second to happen. This left the receiver's time off by a second in the interim.<ref>{{cite web|url=http://www.guralp.com/howtos/leap-second-problem-with-older-gps-receivers.shtml|title=Leap-second problem with older GPS receivers|date=19 November 2014|url-status=live|archive-url=https://web.archive.org/web/20141129055128/http://www.guralp.com/howtos/leap-second-problem-with-older-gps-receivers.shtml|archive-date=29 November 2014}}</ref><ref>{{cite web|url=http://www.spirent.com/Blogs/Positioning/2015/May/How_Leap_Seconds_Can_Interfere_with_GNSS_Receivers|title=How Leap Seconds Can Interfere with GNSS Receivers|date=13 May 2015|url-status=live|archive-url=https://web.archive.org/web/20160306014132/http://www.spirent.com/Blogs/Positioning/2015/May/How_Leap_Seconds_Can_Interfere_with_GNSS_Receivers|archive-date=6 March 2016}}</ref>

* Older Datum/Symmetricom TymeserveTymServe 2100 GPS receivers and Symmetricom Tymeserve 2100 receivers apply a leap second as soon as the a leap second notification is received, instead of waiting for the correct date. The manufacturers no longer supports these models and no corrected software is available. A workaround has been described and tested, but if the GPS system rebroadcasts the announcement, or the unit is powered off, the problem will occur again.<ref>{{cite mailing list|url=http://permalink.gmane.org/gmane.comp.time.nuts/43942|title=Symmetricom TymServe 2100-GPS currently fails with GPS offset|mailing-list=time-nuts|url-status=live|archive-url=https://web.archive.org/web/20150217202809/http://permalink.gmane.org/gmane.comp.time.nuts/43942|archive-date=17 February 2015}}</ref>

* Four different brands of navigational receivers that use data from [[BeiDou]] satellites were found to implement leap seconds one day early.<ref>{{cite web |date=3 March 2015 |title=BeiDou Numbering Presents Leap-Second Issue |url=https://www.gpsworld.com/beidou-numbering-presents-leap-second-issue/ |publisher=GPS World}}</ref> This was traced to a bug related to how the BeiDou protocol numbers the days of the week.