Fetch Timing Info's end time is set to a relative timestamp, when it should be the original captured unsafe current time

[Lubrsi]

What is the issue with the Fetch Standard?

In fetch response handover, step 3.3.2 sets the timing info's end time to a relative timestamp of a previously captured unsafe shared current time. However, this is incorrect because Resource Timing performs the relative timestamp conversion for us.

In responseEnd:

The responseEnd getter steps are to convert fetch timestamp for this's timing info's end time and the relevant global object for this. See fetch for more info.

In setup the resource timing entry:

Initialize entry given the result of converting timingInfo's start time given global, "resource", requestedURL, and the result of converting timingInfo's end time given global.

[annevk]

I think the bug is Resource Timing doing duplicate/incorrect work. I helped design the Fetch aspects of this feature and did not want Fetch to leak any unsafe timing.

cc @noamr

[noamr]

We should use the coarsened shared current time like we do in other places.
It's coarsened but not relative to the time origin.