2 ms·
I don’t understand if this is an actual bug. I have heard that the timing on gps is somehow delivered as weeks and that the bitsize of the variable keeping tra
by callesgg 5y ago
I don’t understand if this is an actual bug.
I have heard that the timing on gps is somehow delivered as weeks and that the bitsize of the variable keeping track of the weeks is to small. So every now and then the weeks reset and this is managed through overrides in the clients. Is this bug not just referencing that thing, the override of the week rollover?
- aidenn0 5y agoYes and no. GPS has 10 bits for the week number (so 1024 weeks) This code is using the number of leap seconds that have happened to sanity group of 1024 weeks we are in. The assumption is that by December of 2022, we would have another leap second, so if we had fewer than 19 total leap seconds, then something has gone wrong. However due to incorrect arithmetic, this sanity check is looking at October 2021. Further comments point out that the sanity check need not be in production code at all, but should be moved to test code.
- fanf2 5y agoGPS also has a field indicating when the previous or next leap second was or will be; this field is 8 bits or about 5 years. The last leap second was in 2016 and no future leap second has been announced. So GPS needs to mark a non-leap to keep the week offset in bounds. This happened before in 2003 during the previous long gap in leap seconds (1998-2005).