Re: Disparity between time bases in HighResolutionTime and ResourceTiming

On Wed, Aug 29, 2012 at 9:57 AM, Jatinder Mann <jmann@microsoft.com> wrote:

> On Tue, Aug 28, 2012 at 6:53 PM, James Simonsen wrote:
> > 1. We really don't want people mixing high res times and UNIX times.
> That's why
> > now() starts at 0 instead of starting from the same value as
> timing.navigationStart.
> > It seems like a bad idea to encourage them to do that, but only in this
> one specific use case.
>
> I believe having the ability to convert between the time bases is
> desirable. We designed the origin of the High Resolution Time to be at time
> 0, the start of navigation of the document, for ease of readability,
> keeping the focus on time since the beginning of the document and freeing
> up bits to provide additional precision. However, if we don't evangelize a
> way to take High Res Time to Unix time, one can't really determine the
> calendar time using performance.now(). E.g., what if I want to know the
> current calendar time in sub-millisecond resolution? What if I want to
> compare performance.now() time stamps from two different browsing sessions?
> This approach keeps it simple; you just add performance.navigationStart.
>

It's impossible to have a high res calendar time, because you don't know
the microseconds when the Date was recorded. A user would be making a
mistake trying to combine the two for that purpose, much as your example
does. This is why we should discourage it completely.

Likewise, now() from two different sessions has the same problem, because
navigationStart doesn't have the resolution. Besides, the user may have
changed their clock between the two browsing sessions, so navigationStart
isn't in the same domain between sessions anyway.

These subtleties are why we should completely discourage it. Our story
should be that we have two different clock mechanisms:

1. Date, which gives you the calendar time, along with all of the pretty
well known caveats.

2. now(), which gives you a reliable high res timer for the current
navigation.

And you shouldn't mix and match. I'd love a way to enforce this, but I
think it'd be way too painful to use.


> > 2. When Navigation Timing 2 is complete, all timing data will be
> available through the Performance
> > Timeline API. However, if your site has iframes, you'll also need to
> ping back timing.navigationStart
> > for each document.
>
> Yes you can, but I don't know if that will be necessary. Each
> sub-document's Navigation Timing 2 and Resource Timing will appear
> independent of the root document; they all start at time 0. However, no
> data is lost as each sub-document will be represented in the root
> document's Resource Timing in its correct order.
>

Agreed. Thanks.


> > It seems like it'd be so much easier if everything "just worked" from
> the web developers
> > perspective: now() would be the same across (same-origin) iframes, and
> they could just
> > concatenate the JSON PerformanceEntryLists from each iframe to build a
> timeline.
>
> Unfortunately, this suggestion creates a privacy leak situation and need
> additional complexity to try to fix the leak.
>

How so? It's not doing anything that can't already be done from JavaScript.
If you're same origin, you can just walk the tree and get all the different
instances of now(). That's exactly how the UA should implement it too. If
we're going to trust millions of web developers to do this correctly, then
we ought be able to trust ourselves to implement it correctly too.

I really don't care about making this harder for us to implement if it
makes it easier for users. There's way more of them than there are of us.


> Further, wouldn't this suggested change complicate the otherwise simple
> timeline for each sub-document? In the current model, each sub-document's
> Navigation Timing 2 or Resource Timing begins at its time 0. With this
> proposal, they would all begin at their root document's navigationStart;
> meaning the sub-document's timeline will be shifted out. If the
> sub-documents are dynamically added, this could mean a very shifted
> sub-document timeline. Seems like another unnecessary complication.
>

Sure. It's nice to have navigationStart always be 0, although that begs the
question why we should have navigationStart at all.

Another way to think of it though, is that the iframe is being navigated
sometime after the root document. So it would follow that its navigation
started sometime later.

James