[1] 次の機能はシステム時計 (によって表される実際の日時) へのアクセスを提供するものです。
[19] 次の機能では、プラットフォームの時差の情報も必要です。
[4] 次の機能は単調増加の時計 (monotonic clock) へのアクセスを提供するものです。
[5] 次の機能は一定時間 (以上) の経過を待ちます。
setTimeout, setIntervalrequestIdleCallback<meta http-equiv=Refresh> HTMLRefresh: ヘッダー 仕様なしtimeout は、毎ミリ秒新たにキューに追加されるマイクロタスクでチェックする形で仕様化されています。getCurrentPosition, watchPosition[214] Retry-After: ヘッダーでも「待つ」時間の規定がありますが、
実装されていないと思われます。
[10] 各プロトコルにもタイムアウト時間があります。
[15] 次のキャッシュも、指定された時間の経過後、無効となります。
It's important to note that some technical oddities in the OS's handling of distinct Chrome processes can cause the clock to be skewed between the browser itself and extension processes. That means that WebNavigation's events' timeStamp property is only guaranteed to be internally consistent. Comparing one event to another event will give you the correct offset between them, but comparing them to the current time inside the extension (via (new Date()).getTime(), for instance) might give unexpected results.
[16] removing 'monotonic clock' section (igrigorik著, ) https://github.com/w3c/user-timing/commit/bb98bce094395f61e92edca5d0cc1e09ab8d07df
[20] John Resig - Accuracy of JavaScript Time () http://ejohn.org/blog/accuracy-of-javascript-time/