Emphasizes that TimeTicks::UnixEpoch() is only an estimate

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.

Committed: https://crrev.com/faa791f2960fb3933b5b8ebd0ca90f81d680ebb4
Cr-Commit-Position: refs/heads/master@{#352952}

[charliea (OOO until 10-5), 2015-10-07 17:43:25]

charliea@chromium.org changed reviewers:
+ miu@chromium.org

[charliea (OOO until 10-5), 2015-10-07 17:43:37]

Patchset #1 (id:1) has been deleted

[miu, 2015-10-07 17:57:17]

lgtm

Follow-up thoughts: I'm beginning to worry we were wrong to ever add this
function, and now I see it's being used in a bunch of places, which is even more
worrisome.  IMO, it's broken that UnixEpoch() is returning a fixed value, but we
know there are many normal scenarios where that value will become totally
incorrect and misleading.  Perhaps we should look into adding some logic for
UnixEpoch() that makes it variable, adjusting to NTP changes.  Callers of this
function would have to all be examined to ensure there's no breakage from this
kind of behavior change.

[charliea (OOO until 10-5), 2015-10-07 18:43:49]

charliea@chromium.org changed reviewers:
+ thestig@chromium.org

[Lei Zhang, 2015-10-07 18:46:53]

lgtm

[charliea (OOO until 10-5), 2015-10-07 18:48:24]

On 2015/10/07 18:43:49, Charlie Andrews wrote:

While I certainly agree that it can have some weird behavior, I think that
pretty much any method that we create will have similar weird behavior. If we
make UnixEpoch() move with NTP adjustments, then it's possible for monotonic
timestamps to move *towards* UnixEpoch() over time, which would surely be
confusing for people too.

I think the most important thing for people to know is that generally, if you're
trying to convert between Time and TimeTicks, you're doing something wrong. I
can think of cases where it might be useful for debugging, but if you follow the
guidelines of which type to use at the top of Time.h, you won't have run into
circumstances where you have to convert.

[charliea (OOO until 10-5), 2015-10-07 19:56:39]

The CQ bit was checked by charliea@chromium.org

[commit-bot: I haz the power, 2015-10-07 19:58:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1391323002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1391323002/20001

[commit-bot: I haz the power, 2015-10-07 21:46:41]

Committed patchset #1 (id:20001)

[commit-bot: I haz the power, 2015-10-07 21:47:52]

Patchset 1 (id:??) landed as
https://crrev.com/faa791f2960fb3933b5b8ebd0ca90f81d680ebb4
Cr-Commit-Position: refs/heads/master@{#352952}