Transactions And Read Write Conflict

How is it that the below scenario is not considered a Read-Write Conflict from this blog post and the docs about Reader encounters write intent or value with newer timestamp far enough in the future?

T2 overwrote a value that was read by T1 even though T1 did not read the value until after T2 had completed.

T1 Starts at 350
Some Long Process 
                                                      T2 Starts at 400
                                                      Write 'current_value' to Key A
						      Commit
Read 'old_value' from Key A
...
Commit

T1 picked its timestamp at 350, so it can read at a consistent snapshot of the database as it existed at time 350. Read-write conflicts as describe in that blog post are for the opposite scenario, when a write is attempted with an older timestamp than a read that has already succeeded.

Ok so as long as a transaction with a lower timestamp does not try to write to a key with a newer read timestamp that is ok.
So in the example if T1 tried to then update Key A right after the read of Key A, would T1 have to be restarted or only be restarted if some other transaction at 410 had already read the value written from T2?
But if T1 was to try and update Key B right after the read of Key A that would be ok since no one with a later timestamp has read Key B.

Yes, if T1 tried to update key A then this is a write-write conflict and T1 would have to restart (because T2 had already committed. If T2 was still pending, then it is possible that T2 would be aborted instead and T1 would be allowed to proceed).

Correct. As long as nothing else has read or written key B at a timestamp greater than 350, then T1 can commit a write to key B at that timestamp.

This is what we mean by serializability: Everything happens as if only one transaction was running a time, even though they actually overlapped. T1 started first, but finished second, so we must figure out where to place it relative to T2. If there is no conflict, then we allow T1 to commit based on its original starting time. If there is a conflict, T1 must restart so its new start time is after T2’s commit.

Thanks for taking the time to explain it.