Parsed UTC timestamps using local date instead of GPS date #24
Comments
richardeoin
added a commit
to richardeoin/nmea-parser
that referenced
this issue
Dec 30, 2021
This applies to the GGA, GLL, GNS and AIVDM type 5 messages. This adheres better to the principle of least surprise for those that are unaware that GGA, GLL, GNS message do not encode the date. It removes the following edge cases: * Processing the same recorded data gives different results depending on the current date * Messages from the same source giving different dates, depending on the configuration of the local machine (reported in zaari#24) Of course, there is an initial surprise when these messages return a date of 2000-01-01 but the user easily learns that these are invalid and that they should use (for example) the RMC message instead. This also allows the dependency of the chrono crate on `std` to be removed, which was the final item preventing this crate from being used in no_std environments.
|
That's a good find. @richardeoin, feel free to make a PR for this project. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a receiver that sends multiple messages with GPS/UTC time. When parsing the timestamp field returns the correct h/m/s, but not the correct date in most cases. (Appends the local computer date) This is most apparent when testing on a machine where the actual date is not the same as the real GPS/UTC date.
The RMC message does parse and return the correct date in the timestamp while the GLL and GGA messages ignore the date. The NMEA string appears to have the same UTC format, but the message parsers here use different utility functions. There may be additional instances in messages I'm not receiving.
The text was updated successfully, but these errors were encountered: