Update the Date in case it's before 2020 due to lapped old GPS.

[htool]

In case of old GPS, the Date part of the pgn will be < 2020. This corrects that, as this pgn should not give a Date < 2020.

[tkurki]

The only problem I see would be parsing data that was captured before the rollover. For that we could have an environment variable to switch this optionally off, but I guess we'll cross that bridge if somebody needs it.

[htool]

Agreed. I first tried to fix it further upstream, but that made some tests fail where Date is use to tell age of certain info.
Hence the somewhat suboptimal re-parsing of the string.

[tkurki]

Can I interest you in adding a test for this? see test/129029.js

[goergevo]

Thank you for this code! I have the same problem with the old GPS on my boat.
I noticed that the code for PGN 126992 has to be changed as well.
And for padding you can use String( ).padStart(2, '0') so you don't need that extra padding function.

[goergevo]

I checked your conversion code an its indeed one day wrong.
"2002-11-18" should be converted to "2022-07-04", but the output is "2022-07-03".

I think its better to base the calculation on ms, this code works correctly:

isoDateString = "2002-11-18T20:13:03Z";     // The original date string from GPS
console.log("old: " + isoDateString);
// expected output: "2022-07-04T20:13:03Z"

// Parse the input ISO date string
const datePart = isoDateString.split('T')[0]; // Extract the date part (YYYY-MM-DD)
const timePart = isoDateString.split('T')[1]; // Extract the time part (HH:mm:ssZ)

// Create a new Date object from the date part
const date = new Date(datePart);

const compensationWeeks = 1024; // Number of weeks to add to the date

// Check if the year is earlier than 2020
const year = date.getUTCFullYear();
if (year < 2020) {
    // Calculate the number of milliseconds in 1024 weeks
    const millisecondsInAWeek = 7 * 24 * 60 * 60 * 1000;
    const millisecondsToAdd = compensationWeeks * millisecondsInAWeek;
    
    // Add the milliseconds to the date
    date.setTime(date.getTime() + millisecondsToAdd);

    // Extract the new date components
    const newYear = date.getUTCFullYear();
    const newMonth = String(date.getUTCMonth() + 1).padStart(2, '0');
    const newDay = String(date.getUTCDate()).padStart(2, '0');

    // Construct the new ISO date string
    // expected output: "2022-07-04T20:13:03Z"
    isoDateString = `${newYear}-${newMonth}-${newDay}T${timePart}`;
}
console.log("new: " + isoDateString);

[htool]

I'm not sure the above works. In case the date is corrected, the timestamp will be now() and the data in the packet will remain old and reaches SignalK, right?

[htool]

Thank you for this code! I have the same problem with the old GPS on my boat. I noticed that the code for PGN 126992 has to be changed as well. And for padding you can use String( ).padStart(2, '0') so you don't need that extra padding function.

That PGN is system time, so it's whatever the system is set to and is isolated from the GPS week rollover.

[htool]

I checked your conversion code an its indeed one day wrong. "2002-11-18" should be converted to "2022-07-04", but the output is "2022-07-03".

I think its better to base the calculation on ms, this code works correctly:
-code-

I'm not saying my code is correct, but I don't see how code that adds ms instead of days or weeks would work differently.

[htool]

BTW, I'm now adding it to signalk-server/packages/streams/canboatjs.js instead of 129029.js to allow a toggle in the interface.