This seems to be working fine. 

> looks like timestamp is set to reload page event and grows from this point.

I'm not sure what you mean by "reload page event" but the times will increase as time passes. The timestamps are in milliseconds.

This is anticipated because of change 
https://developers.google.com/web/updates/2016/01/high-res-timestamps?hl=en

But sending to majidvp@ for resolution in case there is a bug in here.

OK, thanks for the update on that. But the description of the linked article points to a false conclusion:

"The timeStamp property of the Event interface indicates the time at which a given event took place."

So from version 49 on the value doesn't point to the time at which the event took place, instead it points relatively to the navigation point of time. As described further down in the article.

I think that sentence is accurate. It is definitely the "time" of the event but not the "epoch time" (or calendar time) which you are assuming. Time values do not imply epoch origin by default. This is consistent with the wording used in high-resolution timestamp spec [1].

The next few sentences in that article should make clear the time origin that is being used both before and after the change. If that is not clear we should try to address it in the article.

[1] https://w3c.github.io/hr-time/#time-origin 

BTW, I am curious if you could share how this change impacted you in practice (e.g., what functionality broke?) and if you were able to apply any workarounds either from that article or otherwise.

Closing the bug for now as this working as intended. Feel free to re-open if there is any new information that warrants it.

I was comparing the timeStamp with the last on touchmove event (web app) for scrolling a list and calculating the speed of movement. But I considered the timeStamp as a epoch value not as a relative value.

I now built a bridge ("if(chrome){...}") to handle this in another way. As per W3C, as I understand, chrome will handle the event timeStamp in its very own way: 

https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-interface

Thanks for sharing.

I advice against using an "if(chrome)" and instead detecting the time origin and branch your code based on that. Not only because older chrome versions still behave as before but also Firefox is planning to make the switch in the future [1] and the DOM spec is changing as well to reflect this.

A simple way to detect this is to record Date.now() at your application load time and compare the event time stamp with that. See below for a simple example of this that should works for touch events but a more sophisticated approach that works for general events may be found at [2].

// ensure this runs before event handlers are added 
var dateNowAtLoad = Date.now();

ontouchmove = (e) => {
  if (e.timeStamp > dateNowAtLoad) {
    // epoch timestamp -> old path
  } else {
    // high-res timestamp -> new path
  }
}

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1026804
[2] https://github.com/majido/high-resolution-timestamp-polyfill/blob/master/translate-timeStamp.js
 

Ok, I wasn't honest with you. I have a check like your suggestion since already a year when apple released a bug in timeStamp :)

I just do the check now for every browser. So every browser can change now, I am prepared. Thx for your time, I like the support / and chrome.