Our Python job name starts again after restart while the PLC keeps logging, so sorting the mismatched timestamps gives me a lovely story with no basis for choosing which housing attempt owns the acknowledgement.
We had a similar reconstruction fail because the report dropped startup markers. Check the original files for a run boundary and anything carried across both systems, such as an attempt identity or distinctive request sequence, before applying clock offsets.
Startup boundary is there but the acknowledgement carries only the reused job name, and neither trace retains a shared unique request marker, so I've left the two possible attempts in the account instead of picking the nearest time
That is an honest limit for the old incident. For the proposed recording change, test a delayed response across restart and confirm you can distinguish the attempts without relying on the clocks being close.