Why is it that sometimes the time of each documentLoad‘s span is not the time of the Trigger Event(eg: Date.now()), It is based on the time calculated by performance.timeOrigin

[yuanman0109]

in browser, I observed the exported data and found that the request params startTimeUnixNano or endTimeUnixNano of the documentload event was converted to seconds later and Date.Now() is not equal. I don't know whether it is a normal phenomenon. I think that the correct time should be the time of the event;

Take a look at this screenshot, occasionally, endTimeUnixNano is smaller than startTimeUnixNano

[legendecas]

Would you mind sharing the setup you are using to produce the trace results? Specifically, what instrumentation you have enabled to generate the trace?

[yuanman0109]

Would you mind sharing the setup you are using to produce the trace results? Specifically, what instrumentation you have enabled to generate the trace?

Thank you for your reply. I checked the source code and found that the startTimeUnixNano or endTimeUnixNano times of this event are based on performance.timeOrigin(), (eg: xhr plugin end event time is const endTime = (0, core_1.hrTime)(); ), If our browser tag window is not closed, the time will be the same in a few days. but our server needs to know the real-time time of the event. They prefer Date.now(), because they need to query the data of a specific day according to this time.
I want to know how I can change the span's startTimeUnixNano and endTimeUnixNano properties and pass them to the server according to the event occurrence time. And why is the startTimeUnixNano smaller than the endTimeUnixNano ? Or whether there are other ways to meet the server's need for data splitting based on the event occurrence time

[legendecas]

Would you mind sharing the version of the SDK you are using? 5818129 should have fixed this kind of issue. Would you mind verifying with the latest version of SDK?

[yuanman0109]

Would you mind sharing the version of the SDK you are using? 5818129 should have fixed this kind of issue. Would you mind verifying with the latest version of SDK?

tks, The following is the version information of the dependent package. I think I have the same problem as others 3320, 3279 the browser time problem fixed? At present, xhr, fetch, and documentLoad plugin have the same time problem because they all rely on performance.timeOrigin, From the exported data, it can be seen that the endTimeUnixNano time is wrong, which is always less than the startTimeUnixNano time. My browser has not been closed, which will lead to performance in the past.

[yuanman0109]

What's the progress on this issue

[legendecas]

Related: #3279. And #3359 is going to fix it.

/cc @dyladan

[dyladan]

PR is merged and waiting on a release. Closing this since there are already multiple issues open which deal with it