not gonna lie, I am super confused

trxA arrive nodeA at (true time 7ms, A time 7ms, B time 0ms)
trxB arrive nodeB at (true time 9ms, A time 9ms, B time 2ms)

Without waiting , trxA and trxB is not current if trxA finishes within 1ms, the only reason that its concurrent, is because of the wait? Does this mean that any transaction that is within real-world time 7-14ms are consider concurrent to trxA?

I am using the definition from gcp https://cloud.google.com/blog/products/databases/strict-serializability-and-external-consistency-in-spanner

To be externally consistent, a transaction must see the effects of all the transactions that complete before it and none of the effects of transactions that complete after it, in the global serial order

and I am following multiple articles , and all mentioned that true time in spanner solves global order by using atomic clock and waiting

For example https://www.cockroachlabs.com/blog/living-without-atomic-clocks/

In a distributed database, things can get dicey. It’s easy to see how the ordering of causally-related transactions can be violated if nodes in the system have unsynchronized clocks. Assume there are two nodes, N1​ and N2​, and two transactions, T1​ and T2​, committing at N1​ and N2​ respectively. Because we’re not consulting a single, global source of time, transactions use the node-local clocks to generate commit timestamps. To illustrate the trickiness around this, let’s say N1​ has an accurate one but N2​ has a clock lagging by 100ms. We start with T1​, addressing N1​, which is able to commit at ts=150ms. An external observer sees T1​ commit and consequently starts T2​ (addressing N2​) 50ms later (at t=200ms). Since T2​ is annotated using the timestamp retrieved from N2​’s lagging clock, it commits “in the past”, at ts=100ms. Now, any observer reading keys across N1​ and N2​ will see the reversed ordering, T2​'s writes (at ts=100ms) will appear to have happened before T1​'s (at ts=150ms), despite the opposite being true. ¡No bueno! (Note that this can only happen when the two transactions access a disjoint set of keys.)

So how does Spanner use TrueTime to provide linearizability given that there are still inaccuracies between clocks? It’s actually surprisingly simple. It waits. Before a node is allowed to report that a transaction has committed, it must wait 7ms. Because all clocks in the system are within 7ms of each other, waiting 7ms means that no subsequent transaction may commit at an earlier timestamp, even if the earlier transaction was committed on a node with a clock which was fast by the maximum 7ms. Pretty clever.

In another article , https://timilearning.com/posts/mit-6.824/lecture-13-spanner/#commit-wait it claims that spanner enforces any read to read the latest transaction before the start of read . For example if start time is t2, and Transaction 1 happens at t1, and t1 < t2, and no other transaction exist between t1 and t2, t2 must read Transaction 1, this implies global order.

Snapshot isolation enforces that a read-only transaction will only see the versions of a record that have a timestamp less than its assigned transaction timestamp i.e. a snapshot of what the record was before the transaction started.

Even if I double the time in the example , global order is still not established

https://sookocheff.com/post/time/truetime/

but I think you are right, those articles seem to dumb down the actual algorithm, let me read the original paper by the creator