A CL just landed to address this: 
https://codereview.chromium.org/2057243003

screenshot attached.
 
does this work for you?

Deleted: 9c8b742a-2d0a-4797-af6e-29341463222d.png 67.9 KB

	9c8b742a-2d0a-4797-af6e-29341463222d.png 67.9 KB View Download

Hey Paul, thanks for looking at this.

Maybe I'm missing it, but I don't see a timestamp in that screenshot. If you are referring to the "Started at 10.21ms" I'm unclear how that's a timestamp or how that's useful. Is that a relative time to the start of the page load sequence where the timestamp for that is indicated elsewhere? If not, could you highlight or circle where the timestamp is?

To clarify, what I'm looking for is an absolute timestamp for start and end of the individual request as recorded by the browser in local time. Something like "2017-02-21 14:14:16.576", or just the time part omitting the date for brevity. eg: Hour:Minute:Second.Milli/Microsecond

> Is that a relative time to the start of the page load sequence where the timestamp for that is indicated elsewhere? 

yes its relative to navigationStart, which is generally considered the time origin of a page. It's from the monotonic clock, which is considered the most accurate way of measuring time and not worrying about computer sleep, time zones, leap seconds, etc.

Can you explain your usecase for knowing the wall time? 

> Can you explain your usecase for knowing the wall time? 

i'm not the OP, but they are invaluable for correlating requests between different tools. for an example that is limited to devtools itself, it can be useful to know whether an xhr triggered a websocket frame or vice versa ... websocket frames show a timestamp, xhr shows relative time

> Can you explain your usecase for knowing the wall time? 

(I'm not the OP either.)

In my usecase, I noticed a console log message (with timestamp 11:10:20.606) from my application that said an xhr response was malformed (json truncated, apparently).  However, I wasn't able to tie that to a particular network request because I couldn't find the packet by timestamp.

I tried to work around this by adding an extra header column of 'Date', but found the server is reusing the 'Last-Modified' value as the 'Date' value.  Even if it did give the current time, it's from a clock of unknown accuracy, and it doesn't show milliseconds.

Eventually I just saved it as a HAR file and looked for the time that way:

    "entries": [
      {
        "startedDateTime": "2018-03-02T19:45:50.459Z",
        "time": 189.73837304458723,

My use-case is that I have an ajax calls with the timeout of 1 second, and my handler tells me that that call is timeouted. I have some logging and can see in the Console tab that indeed, between request start and timeout message there is about 1 second.
But the thing is, the Network tab tells me that request takes less than 200 ms and it has status 200.
To understand that further I want to correlate request start timestamp from the Network tab with the logs from the Console tab, but I can't.

I wonder, what is the justification of giving us only the relative times, instead of absolute ones?