Use the server’s clock when it’s obviously better than the client’s

[liZe]

This is the last part of the timestamp algorithm: https://azafea.readthedocs.io/en/latest/timestamp-algorithm.html#server-side

"When the server receives a network request, it will first examine the network request absolute time to see if it varies significantly from its own (trusted) clock. If it does, some special action will be taken with that request, such as putting it in its own special table or attempting to correct the timestamp in some fashion."

Our "attempt to correct the timestamp" happens when:

• the request is received before it has been sent (1 second tolerance),
• the request is received a long time after it has been sent (10 minutes tolerance). In these two cases, we prefer to use the server’s clock, because the client’s clock is obviously wrong.

~https://phabricator.endlessm.com/T29275~ https://phabricator.endlessm.com/T32195

[wjt]

Wrong ticket, I think https://phabricator.endlessm.com/T32195 is the one, and the linked one can track the existence of the problem for existing v2 data.

@dbnicholson could you take a look here?

[liZe]

It fixes ~10% of the events we will receive. For the record, interesting stats are here: https://phabricator.endlessm.com/T31727#884096.

[liZe]

Looks good. I don't know how the test was passing before, but this makes more sense.

When the difference is big, we keep the server time, no matter how big the difference is. The difference was huge with the previous code, it’s now just an hour, but the result is the same and the test passes in both cases.