Chrome Version : 24.0.1312.56
OS Version: OS X 10.8.2
What steps will reproduce the problem?
1. open chrome://net-internals
2. suspend system (close lid)
3. clear net internals events
4. open a web page
5. examine net internals events
What is the expected result?
new events should have current time
What happens instead of that?
times are wrong. they're shifted backwards by the amount of time spent asleep.
e.g., if i resume at 4:00pm, after the system was asleep for 2 hours, the net-internals
timestamps will be 2:00pm.
workaround: close net-internals and re-open it.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17

The issue is that the NetLog uses timetics (base::TimeTicks()) rather than timestamps (base::Time()) when capturing events.
The behavior of timeticks across sleeps is platform specific (may or may not increase). Which makes converting them to timestamps unreliable if there were intervening sleeps.
I initially chose to use timeticks rather than timestamps to avoid the possibility of time moving backwards in events (if a user changes their system clock, later events may actually have an earlier timestamp).
The performance tradeoff between the two is negligeable.
Given this usecase, I think switching to using timestamps in place of timeticks might be a better tradeoff. (Likely more common to encounter suspend/resume than dramatic system clock changes; although with network time synching shifts in timestamps would also be expected).
The other possibility is to log suspend/resume events in the NetLog (something which we probably want to do anyway), and make note of the new timetick --> timestamp adjustment each time, so we can rebuild correct timestamps

The two potential concerns are how monotonic it is and what its resolution is.
I assume the main causes of lack of monotonicity would be users modifying it and NTP (Network Time Protocol, not to be confused with the New Tab Page).
Resolution differences are presumably platform dependent.

Some extra data:
* base::TimeTicks advances during sleep for Windows, however not Mac/Linux/Chromeos
* the performance of base::TimeTicks::Now() and base::Time::Now() are pretty much identical.
On my Linux setup I got these runtimes:
Time::Now -- 39.95 nanoseconds
TimeTicks::Now -- 38.06 nanoseconds
According to a post on chromium-dev, scottmg reports Windows runtimes of 50 nanoseconds for each.
Ideally we would have a time class that could be used on all platforms to accomplish this.
Not sure what is worse -- using Time::Now() and potentially having the times in NetLogs jitter due to NTP, or using TimeTicks::Now() and having weirdness on Mac/Linux whenever the system is suspended.
Barring a suspend-independent tick class, I believe that Time::Now() is the lesser of the two evils.

What about resolution? Know that on at least some windows platforms, timegettime used to have pretty bad resolution. And accuracy was dependent on whether the "high resolution media timer" was active or not.

Perhaps then I will suggest adding something like:
base::BootTicks
This will have the behavior of monotonically increasing, and reflect time spent in suspends. Or we should just define TimeTicks to act that way.

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot