The obvious evidence are the laws of physics which are invariant under time translation. What you are saying is exactly what I said - it does not matter if the drifting clocks are in different parts of a distribute system or if a single system uses different clocks. In the end the system fails because different clocks disagree on the current time, not because they drift away from the actual time. And the article states exactly this - they tried to fix the clock drift relative to the actual time but failed to do so in all components and thereby inadvertently introduced two clocks drifting relative to each other.
In the end the system fails because different clocks disagree on the current time, not because they drift away from the actual time.
The possibility I mentioned was that the clocks disagreed because they had drifted away from actual time at similar rates, for different periods. [r ≠ 1 ∧ t₀ ≠ t₁] → [t₀ + (t-t₀)r ≠ t₁ + (t-t₁)r]. Unless specifically addressed, this phenomenon will occur in distributed systems.
That said, the link 'gibrown provided seems to establish firmly that this particular error resulted from times being up-converted (24bit fixed to 48bit floating) via different methods in different parts of the system.
Now I see what you mean, equal drift rates but different up-time. Assuming two clocks coming up at different points in time this will indeed cause time differences if they are initially synchronized with a third clock. If the clock coming up later synchronizes with the other clock already running there should be no issues though.
I read the article, too, and this two different ways of converting are more or less equivalent of two clocks starting in sync but drifting relative to each other. Therefore my initial comment was quite on the spot.
Yep, that's how I read the article, the target path prediction system was 0.34 seconds out of sync with the targeting system due to differing implementations.
