Unfortunately due to limitation on windows, we cannot always assume that we have a monotonic clock that is consistent across processes. In particular anytime we fallback to using |timeGetTime()| then there cross process See [1,2] for more information.

This means that any logic that relies on comparing timeticks that are from different processes can be experience unexpected skew which may lead to bugs.

Here are a few examples of when this occurs:
 - Anytime we expose a timeticks from a non-renderer process to the web (e.g., resource timing, high-resolution event timestamp)
 - Anytime we compare an event timestamp (generated in UI process) to TimeTicks::Now() in renderer. e.g., when computing Event.Latency.Renderer2
 - Anytime we compare an network resource timestamp to a timestamp in a different process e.g., https://code.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.cc?sq=package:chromium&dr=CSs&rcl=1464852061&l=1317 

There are several ways to deal with this issue:

1. Try to measure the skew and adjust for it. This is the approach taken by InterProcessTimeTicksConverter (IPTTC) which relies on at least two IPC between involved processes. We probably need a different (less expensive) approach for event timestamps.
2. Do not compare timestamps across processes when clock is not consistent. For example we could do this for some UMA metrics. 
 

[1] https://docs.google.com/document/d/1RcaOZ1G8ttAez9YuilvbDJCkCaYuLKqNkVpQvIBqsvM/edit
[2] go/timeticks