Emphasizes that TimeTicks::UnixEpoch() is only an estimate
This is the case because of its implementation:
- Use Time::Now() to determine the current distance to the Unix epoch
- Subtract that distance from TimeTicks::Now(), giving you an
approximation of that epoch in TimeTicks
However, this can lead to strange situations:
- If a system experiences a large NTP adjustment (say, after being
offline for a while), then Time::Now() will immediately jump to the
new time, whereas TimeTicks::Now() will very slightly speed up or
slow down the clock until the monotonic clock matches what's thought
to be the "correct" time. However, this means that for a 10 second
NTP adjustment, calling TimeTicks::UnixEpoch() a second before the
adjustment will yield a 10 second difference from calling it after
the adjustment.
- The same is true for when the user manually sets the clock. Any
monotonic clock (those used for TimeTicks) is resistant to such
user intervention, whereas any wall clock (used for Time) is
usually not. Thus, calling TimeTicks::UnixEpoch() a second before
such an adjustment will yield a vastly different epoch estimate
than calling it after the adjustment.
Both of these are somewhat surprising results for a TimeTicks function,
as it's generally safe to assume that TimeTicks functions are immune to
these strange jumps.
Given all of this, I think TimeTicks::UnixEpoch() needed a slightly
stronger warning about the fact that it's only an estimate.
Review URL: https://codereview.chromium.org/1391323002
Cr-Commit-Position: refs/heads/master@{#352952}
CrOS-Libchrome-Original-Commit: faa791f2960fb3933b5b8ebd0ca90f81d680ebb4
1 file changed