The parseTimestamp function is doing 99,9% of the parsing perfectly except it is one month ahead in a few specific edge cases. When a month has 31 days and the next one does not, the parsed timestamp will "rollover" a month ahead more when the current date is at the end of the month (happening 5 times a year at the end of these specific months). This for the duration of the difference to UTC relative to the time zone at the current system time. How to reproduce; example behaviour:
"Raw" timestamp string from p1 meter that is to be parsed: "240201000215W",
(the below function should result in the expected return of: "2024-02-01T00:02:15.000Z")
where the below instantiated parsedTimestamp at the instantiated moment with new Date() has a
"starting" date of "2024-01-31T23:02:15.000Z" (it uses the current system time to set the value it seems, at least in my use case).
function in question:
gives a returned date of: "2024-03-01T00:02:15.000Z", one month ahead of the expected "Raw" data.
One proposed solution is to change the order of operations; first set the Miliseconds, then seconds, minutes, hours, date, month and finally the year. This prevents this edge case where the Month rolls over and goes +2 instead of +1 as per P1 expected raw input.
This was an issue for me as i used the p1-reader timestamp as the timestamp to log the data into an influx db instance and i was missing data at the start of February, April, June, September and November. The data was still there, but logged into the database one month ahead of the actual date.
The parseTimestamp function is doing 99,9% of the parsing perfectly except it is one month ahead in a few specific edge cases. When a month has 31 days and the next one does not, the parsed timestamp will "rollover" a month ahead more when the current date is at the end of the month (happening 5 times a year at the end of these specific months). This for the duration of the difference to UTC relative to the time zone at the current system time. How to reproduce; example behaviour:
"Raw" timestamp string from p1 meter that is to be parsed: "240201000215W", (the below function should result in the expected return of: "2024-02-01T00:02:15.000Z") where the below instantiated parsedTimestamp at the instantiated moment with new Date() has a "starting" date of "2024-01-31T23:02:15.000Z" (it uses the current system time to set the value it seems, at least in my use case). function in question:
gives a returned date of: "2024-03-01T00:02:15.000Z", one month ahead of the expected "Raw" data.
One proposed solution is to change the order of operations; first set the Miliseconds, then seconds, minutes, hours, date, month and finally the year. This prevents this edge case where the Month rolls over and goes +2 instead of +1 as per P1 expected raw input.
This was an issue for me as i used the p1-reader timestamp as the timestamp to log the data into an influx db instance and i was missing data at the start of February, April, June, September and November. The data was still there, but logged into the database one month ahead of the actual date.