Geth and Parity nodes differ in a fundamental way when they validate block headers.
According to the yellow paper
4.3 timestamp: A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally Hs
4.4 Hs is the timestamp of block H and must fulfil the relation: Hs > P(H)
Both implementations require that the machine running the node to resolve it's NTP protocol to
pool.ntp.org for no more than 10 seconds
But, they differ when it comes time to validate the block. Geth and parity will check if that timestamp is greater than the parent's timestamp, but geth will outright reject any block that has its current time set in the future
Given the fact that parity allows for a looser interpretation of timestamp validity, how do these protocols resolve on different blocks being proposed, does the stricter protocol win in the end? Additionally, is there a way to quantify this variation of timestamps?