[HN Gopher] Gpsd bug may create a 1024 week time warp on October 23
___________________________________________________________________
Gpsd bug may create a 1024 week time warp on October 23
Author : oger
Score : 53 points
Date : 2021-08-02 18:53 UTC (4 hours ago)
(HTM) web link (gitlab.com)
(TXT) w3m dump (gitlab.com)
| callesgg wrote:
| 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 wrote:
| Yes 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.
| dheera wrote:
| Why do people use gpsd instead of just reading $GPGLL or $GPRMC
| from /dev/ttyACM0 or /dev/ttyUSB0 or whatever, which always
| seemed far more reliable to me?
| gsich wrote:
| Allows multiple applications to use a GPS source.
| fisherjeff wrote:
| Somewhat unrelated: Can someone explain the rationale for writing
| comparisons in the ordering they're using (e.g., 2180 < week)?
|
| I've seen similar before and always thought it seemed error-prone
| to not write them the way they'd be spoken aloud, but happy to
| entertain other explanations.
| gabagool wrote:
| Even more unrelated, but equally pedantic, I've always thought
| it's weird when people write "null != val" instead of "val !=
| null" for the same reason.
|
| When said out loud, "null is not val" just feels wrong.
| hobs wrote:
| In PowerShell you'll get a linter warning because things like
| (look at the -):
|
| if (@() -eq $null) { 'true' }else { 'false' } # false
|
| if (@() -ne $null) { 'true' }else { 'false' } # false
| new_guy wrote:
| Isn't that just Yoda notation?
| https://en.wikipedia.org/wiki/Yoda_conditions
| LukeShu wrote:
| I've seen style guides recommend that to avoid typos on == that
| accidentally result in assignment: write "123 == foo" instead
| of "foo == 123" so that you can't accidentally write "foo =
| 123".
| fisherjeff wrote:
| I can get on board with this, as it scans the same both
| directions
| bobbylarrybobby wrote:
| Surely such code would be caught by some other tool, and
| isn't worth the mental overhead to translate it back into the
| more natural form?
| Groxx wrote:
| "Natural" is both not universal, and re-trainable. `value
| [op] var` is quite common in many circles, it _is_ natural
| to many of those coders.
| throwaway3neu94 wrote:
| It's not only about not accidentally writing `if (x=0)`.
|
| The `if (0==x)` style also makes it obvious that the check
| is correct when reviewing/reading code. Sure, a linter
| might catch this. But this way the reader doesn't need to
| rely on that. Besides many codebases allow variable
| assignment as part of conditional/loop expressions, and
| sometimes sadly it's easier to write code this way than to
| get a team to use a linter.
|
| Regarding it being unnatural... you get used to it, and
| especially in C one needs to take care to check the return
| code the right way (0!=, 0==, -1!=, 0<, !, etc.), whereas
| the other side of the check is often more straightforward
| (a function call, a variable etc.), so it's nice to have
| the constant up front. It takes very little extra space at
| the front. As a bonus all the constants will visually line
| up nicely that way.
| bena wrote:
| I assume it's a habit formed from guarding against
| unintentional assignment.
|
| Less so for most comparisons, but for equality, it'll throw an
| error if you're using the wrong operator instead of having
| unintended side effects.
|
| week = 2180 will set the week to 2180 in a lot of languages.
|
| 2180 = week will always throw an error.
|
| So if I want to compare, it's safer to use the form of 2180 ==
| week because if I forget the second '=', the compiler will tell
| me before I make bigger problems.
| craigds wrote:
| Being unfamiliar with GPSD, what devices/services would this be
| likely to affect?
| wmf wrote:
| NTP servers.
| axus wrote:
| We just replaced some old GPS time-servers that have a similar
| bug.
| benbojangles wrote:
| oh cool, because that's my birthday
| colejohnson66 wrote:
| How do we not have a way to predict leap seconds?
| kelnos wrote:
| I believe we used to, but only recently have we began to
| understand that the Earth's rotation is not slowing down in a
| linear/predictable fashion. A comment on the bug says this has
| something to do with global warming, but I don't really have
| much context here.
| btilly wrote:
| The Earth's rotation is complicated. See
| https://www.smithsonianmag.com/smart-news/global-warming-
| cha... for how global warming is theoretically speeding up
| the Earth's rotation (melting ice causes land to rise at the
| poles, and moving rock turns out to be more important than
| water migrating from pole to equator) and
| https://phys.org/news/2015-12-scientists-reveal-rotation-
| ear... for how interactions of the core, mantle and crust are
| currently slowing the day down.
| crote wrote:
| Leap seconds correct for the difference between the time as
| measured by atomic clocks and the time determined by solar
| observations.
|
| Turns out the rotation speed of Earth varies. Things like
| tides, earthquakes, and climate change can affect it. There is
| no formula for that, the only thing you can do is measure and
| issue a leap second when required.
| oceanghost wrote:
| We're floating through space and that space doesn't have a
| uniform shape and then there's the n-body-problem.
|
| Interestingly enough we're finding out that a lot of our solar
| cycles are probably due to massive things in very long orbits
| in our solar system.
| packetslave wrote:
| Quoting from that thread:
|
| > I don't think gpsd has any reason to be predicting when a
| future leap-second is going to occu
|
| Until last year, leap seconds had been very predicable. The
| effect of global warming on earth rotational speeds was only
| very recently seen, or even predicted. But, yes, going forward,
| that needs to change.
|
| > And the code in question is clearly expecting only positive
| leap-seconds.
|
| Yes, because until 2020, the thought of a negative leap second
| was unthinkable. I would welcome you testing that and seeing
| what falls out.
| nonfamous wrote:
| The number of leap seconds required is determined by the
| Earth's rotation speed, which isn't constant. In the same way
| that an ice skater extending his arms slows down, shifts in
| mass on the Earth can alter its rotation speed. Earthquakes,
| icemelt, atmospheric warming, and even the filling of the Three
| Gorges Dam can have an effect at the scale required for GPS
| synchronization.
| swman wrote:
| It'd be cool if we could just invent a new standard time system
| that's independent from things like that which add variation or
| unexpected randomness.
|
| I mean sure it would be annoying but its a one time change and
| our generation has to endure the pain of upgrading our systems,
| but it would be worth it no?
| wmf wrote:
| There's not really anything to invent or upgrade. Just never
| add any more leap seconds (the past ones can't be safely
| removed). We need to lobby the IERS harder.
| Smaug123 wrote:
| I'd be interested to hear how you're going to bring it into
| alignment with GMT and the other Sun-and-Earth-based
| measuring systems which people are actually going to want to
| use. Note that the solar day does vary unpredictably in
| length
| (https://en.wikipedia.org/wiki/Day_length_fluctuations).
___________________________________________________________________
(page generated 2021-08-02 23:00 UTC)