NMEA: handle date already in ddmmyyyy format

[graham8]

Trimble CoPilot outputs GPRMC with the full year. Non-standard and probably unique but this one-liner should fix it.

[robertlipe]

Thanx and welcome!

Im in bed and not looking at whole code, but I'm skeptical about this.

Could you please edit twsto.nema.test and add a comparison that conberts a snippet of a file that would have been mishandled (just a stanza or even one line) in reference/track/Sony.nmea and compares it to known working unicsv output in references/track/Sony~unicsv?

Adding a linki. The source or in XML doc/formats/nmea. XML would also help us figure out why there's a sill. Think here.

It may be easier to do addition in the numeric domain instead of string. Pseudo code

Int d = field.toint()
If d > 2000 d -= 2000
Now stringify d and use it like others

When you're done tearing with "testo nmea*, you can run the whole suite with just testi. When you next push,. GitHub will run that automatically, including in more tortured modes.

It may sound like a lot, but There are many examples of all this.

Thanks.

[graham8]

It may sound like a lot

Indeed it does. I'm not familiar with your build system or testing system and can't find any files Sony* anywhere.

If I thought this would benefit a number of users I might devote some time to it but I suspect this is unique to CoPilot and as a 'SatNav' app aimed at road drivers I doubt many are using this (undocumented) feature. Here is a snippet of the offending file:

$GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
$GPRMC,092757.000,A,5108.0055,N,00116.7411,E,22.96,110.57,27072023,,,A*55
$GPGGA,092757.000,5108.0055,N,00116.7411,E,2,12,00.0,00167.4,M,0.00,M,,*6F

I just thought it was trivial not to add '20' to the date string (and can't see why doing it numerically would be easier). But if you are concerned it will cause issues elsewhere it's probably not worth pursuing. I can just specify the date manually or sed the GPRMC lines.