It seems you are in timezone Europe/Berlin or similar and currently have a 2-hours positive offset to UTC.

The timestamp in ISO format should specify the timezone as a suffix. Z would be UTC. Your measurementTimestamp however is missing the suffix, and new Date interprets that as "the current local timezone" (in your case +02:00) which is why you get a discrepancy here.

You can add the missing Z to the measurementTimestamp to solve this problem:

(new Date('2021-09-24T15:38:18.569Z') - new Date('2021-09-24T15:37:46.612Z')) / 1000
//                                                                       ^
// Result: 31.957

Important: This is not the same as removing the Z from the other timestamp because then you would actually compare two times in local timezones (and in fact times that are irrelevant to anything you really care about, because they are the result of interpreting UTC times as local times which then point to a different moment in time).

You may think that this doesn't matter because if both of them are local now, the offset should cancel out, right? ...but this is not the case if there is a daylight-saving time boundary between the timestamps you compare! If both are UTC, they are absolute (there is no daylight-saving time in UTC as such - it would be in Europe/London but that's not the same), but in your local timezone you can have clocks being moved back and forth an hour twice a year (Europe/Berlin is +02:00 for half a year and +01:00 for the rest of the time).

See these results I get (I'm in Europe/Berlin):

(new Date('2021-03-28T03:00:00Z') - new Date('2021-03-28T01:00:00Z')) / 1000
// Result: 7200

(new Date('2021-03-28T03:00:00') - new Date('2021-03-28T01:00:00')) / 1000
// Result: 3600 (!!!)

The clock was moved forward at March 28th, 2021 from 02:00 to 03:00 here. So, comparing these two times of 03:00 and 01:00 with local timezone gives me only one hour difference instead of two! If I now actually intended to compare 03:00 UTC with 01:00 UTC, I got a totally wrong result and it can ruin my day.

Let me add one more, even worse, example to this:

(new Date('2021-03-28T03:30:00Z') - new Date('2021-03-28T02:45:00Z')) / 1000
// Result: 2700

(new Date('2021-03-28T03:30:00') - new Date('2021-03-28T02:45:00')) / 1000
// Result: -900 (???)

03:30 should be 45 minutes (2700 seconds) after 02:45, right? Then how come we got a negative number now of -15 minutes? Well, in my local time, 02:45 doesn't even exist because after 01:59 came 03:00 on that day... and it's treated the same as if you would try to set a date like 31st of November in JavaScript (which would be handled like 1st of December) - it rolls over and is treated the same as 03:45.

OK, probably got it: I need to remove the Z character from toISOString format. It works, but I'm not sure, if its correct approach.

(new Date(new Date().toISOString().slice(0,-1)) - new Date(measurement.measurementTimestamp))/1000