hr-time-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>High Resolution Time（日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">

<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>
Util.ready = function(){
	const source_data = {
		generate: expand
	};
	Util.switchWordsInit(source_data);
}

function expand(){

	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w~\-一-鿆あ-ん]+|`(.+?)([$@\^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!key) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#bib-${key.toLowerCase()}`;
	break;
case 'm':
	const n = text.indexOf('(');
	if(n > 0){
		key = text.slice(0, n);
		text = key + text.slice(n).replace(/\w+/g, '<var>$&</var>');
	}
	break;
case 'l':
	text = `"<code class="literal">${text}</code>"`;
	break;
case 'test':
	href = `https://wpt.live/hr-time/${key}.html`;
	text = '【~test】';
	break;
case 'en':
	return `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;


	}
}

</script>

<script type="text/plain" id="_source_data">


●●options

spec_date:2024-11-07
trans_update:2024-11-13
source_checked:230112
page_state_key:TIMING
original_url:https://w3c.github.io/hr-time/
	abbr_url:HRTIME
spec_status:ED
ref_id_prefix:bib-
ref_id_lowercase:true
conformance:w3c
copyright:2024,permissive
trans_1st_pub:2015-07-22


●●class_map
E:dom-error

●●tag_map
I:code
m:code
d:code
c:code
E:code
v:var
b:b
i:i
cite:cite

●●original_id_map

●●mdn_urls
dom-domhighrestimestamp:API/DOMHighResTimeStamp
dom-performance:API/Performance
dom-windoworworkerglobalscope-performance:API/Window/performance
	dom-windoworworkerglobalscope-performance:API/WorkerGlobalScope/performance
dom-performance-now:API/Performance/now
dom-performance-timeorigin:API/Performance/timeOrigin
dom-performance-tojson:API/Performance/toJSON

●●link_map


Replaceable:~WEBIDLjs#Replaceable
Exposed:~WEBIDLjs#Exposed
Default:~WEBIDLjs#Default

unsigned long long:~WEBIDL#idl-unsigned-long-long
double:~WEBIDL#idl-double
object:~WEBIDL#idl-object

I.DOMHighResTimeStamp:#dom-domhighrestimestamp
I.Performance:#dom-performance
I.WindowOrWorkerGlobalScope:~HTMLGAPI#windoworworkerglobalscope
	#dom-windoworworkerglobalscope-windoworworkerglobalscope
I.EpochTimeStamp:#dom-epochtimestamp

I.Window:~WINDOW#window
I.Worker:~WORKERS#worker
I.SharedWorker:~WORKERS#sharedworker
I.ServiceWorker:~SW1#serviceworker
I.EventTarget:~DOM4#eventtarget
I.BroadcastChannel:~HTMLcomms#broadcastchannel

m.performance:#dom-windoworworkerglobalscope-performance
m.now:#dom-performance-now
m.timeOrigin:#dom-performance-timeorigin
m.toJSON:#dom-performance-tojson
m.timeStamp:~DOM4#dom-event-timestamp
m.postMessage:~HTMLcomms#dom-window-postmessage-options

c.Date:~TC39#sec-date-objects
c.Date.now():~TC39#sec-date.now
c.Temporal.Instant:https://tc39.es/proposal-temporal/#sec-temporal-instant-constructor

	●用語
外的な時計~調整:#_clock-adjustments
時計:#dfn-clock
安全でない現在の時刻:#dfn-unsafe-current-time
壁~時計:#dfn-wall-clock
壁~時計の安全でない現在の時刻:#wall-clock-unsafe-current-time
単調増加~時計の安全でない現在の時刻:#monotonic-clock-unsafe-current-time
安全でない~moment:#dfn-unsafe-moment
粗化した~moment:#dfn-moment
~moment:#dfn-moment
所要時間:#dfn-duration
所要時間を得る:#dfn-duration-from
所要時間を時刻印に暗黙的に変換する:#dfn-implicitly-convert-a-duration-to-a-timestamp
現在の相対的な時刻印:#dfn-current-relative-timestamp
現在の単調増加~時計~時刻:#dfn-current-monotonic-time
粗化した現在の壁~時計~時刻:#dfn-current-wall-time
enV.現在の壁~時計~時刻:#dfn-eso-current-wall-time
~Unix~epoch:#dfn-unix-epoch
単調増加~時計において~Unix~epochを成すものと見積もられる時刻:#dfn-estimated-monotonic-time-of-the-unix-epoch
単調増加~時計において~Unix~epochとして見積もられる時刻:#dfn-estimated-monotonic-time-of-the-unix-epoch
~Unix~epochとして見積もられる単調増加~時計~時刻:#dfn-estimated-monotonic-time-of-the-unix-epoch

時刻~起点の時刻印を取得する:#dfn-get-time-origin-timestamp
時刻~起点の時刻印:#dfn-get-time-origin-timestamp
時刻を粗化する:#dfn-coarsen-time
相対的な高分解能~時刻:#dfn-relative-high-resolution-time
相対的な粗い高分解能~時刻:#dfn-relative-high-resolution-coarse-time
現在の高分解能~時刻:#dfn-current-high-resolution-time
単調増加~時計:#dfn-monotonic-clock
粗化した共有される現在の時刻:#dfn-coarsened-shared-current-time
安全でない共有される現在の時刻:#dfn-unsafe-shared-current-time

	●用語（外部
実装定義:~INFRA#implementation-defined
~UA:~INFRA#user-agent
追跡~行路:~INFRA#tracking-vector

文書:~DOM4#concept-document
	Document:~DOM4#document

~navi:~HTMLnav#navigate
近しい:~HTMLds#familiar-with

環境~設定群~obj:~WAPI#environment-settings-object
関連な大域~obj:~WAPI#concept-relevant-global
関連な設定群~obj:~WAPI#relevant-settings-object
大域~obj:~WAPI#global-object
rM.大域~obj:~WAPI#concept-realm-global
enV.時刻~起点:~WAPI#concept-settings-object-time-origin
enV.非同一-生成元~能力は隔離されるか？:~WAPI#concept-settings-object-cross-origin-isolated-capability

~workerを走らせ:~WORKERS#run-a-worker

既定の~toJSON手続き:~WEBIDLjs#default-tojson-steps

~JS時刻:#dfn-time
	~JS時刻:~TC39#sec-time-values-and-time-range

cite.User Timing:~USER-TIMING#user-timing-ja.html

rP.時刻印:~REPORTING#report-timestamp

●●words_table1

USER-TIMING:user-timing-ja.html

●●words_table


	●計時
zero::::ゼロ
moment:
時系列順:chronological::~
計測-:instrument:~
分解能:resolution::~
高分解能:high resolution::~
時計:clock::~::クロック
壁:wall::~
	従来の時計:time-of-day
	数:number
milli:milli-:::ミリ
micro:micro-:::マイクロ
nano:nano-:::ナノ
	~milli秒:milliseconds
	~milli秒数:in milliseconds
	~milli秒数:the number of milliseconds
	~milli秒数:number of milliseconds
	~milli秒より細かい:sub-millisecond
	~micro秒:microseconds
	~nano秒数:number of nanoseconds
	秒:seconds
	整数な:integral
単調増加:monotonic::~
単調増加-:monotonic に increase::~
減少-:decrease::~
rate::::レート
費やさ:elapseさ:~
暦:calendar::~
Unix:
epoch:
周期的:periodic:~
周期:interval:~
定期的:regular:~
カクつき:jank:~
閏秒:leap second:~
計量:metric::~
経過:passage:~
現実世界:real-world:~
数える:countする:~
早期:early:~
近似的:approximate:~
	約:approximately
齢:age:~

	時間~原点:time origin::~
起点:origin::~
粗化-:coarsen:粗く
	粗化した:coarsened
	〜より粗化した:coarsen 〜 not exceed
粗い:coarseな:~
固定的:fixed:~

	挿入:cue
	^en:skew
	長時間:longer time period
	確度
	高:high
	正確aさに抑える:minimum 〜 inaccurate
	正確aさ:accurate to
	ゆらぎを加える:Added jitter
	任意選択で ゆらぎも加える:and potentially jitter 
	計時~側からの:timing side-channel
	利用者による`外的な時計~調整$:situations when the user adjusts their clock either forward or backward
	早くまたは遅く流れる:runs slow or fast
	追跡できなくなる:loses track of
	より~~過去を指す:came before
	齢:age:~
	何日後かに失効する何か:Multi-day attribution report expirations
	有効期間:expiry
	何日か:days
	一点:point

	●処理
稼働時の:runtime::~
再起動:restart:~
安定的:stable::~
main::::メイン
丸めた:roundした:~

	各~開始:restart
	渡-:pass
	~~頻度を抑えるよう〜絞る:throttle

	%G:global
	%a
	%b
	%d
	%~data:data
	%~event:event
	%~epoch時刻:epoch time
	%~moment:moment
	%~source:source
	%入力:value
	%単調増加~時計~時刻:monotonic time
	%報告:report
	%壁~時計~時刻:wall time
	%安全でない単調増加~時計~時刻:unsafeMonotonicTime
	-:unsafeWallTime
	%文脈:context
	%時刻:time
	%時刻印:timestamp
	%時計:-
	%時間~分解能:time resolution
	%時刻~起点:timeOrigin
	%現在の時刻:-
	%粗い時刻:coarse time
	%設定群:settings
	%設定群~obj:settingsObject
	%非同一-生成元~能力は隔離されるか:crossOriginIsolatedCapability
	%所要時間:-

	●保安
schedule::::スケジュール
timer::::タイマー
統計的:statistical:~
活動:activity:~
速度:speed:~
露呈-:reveal:露わに
応答性:responsiveness:~
協調-:coordinate:~
退歩:regressions:~
分析:analysis:~
分析-:analyze:~
音:sound:~
見積もり:estimate:~
見積もら:estimateさ:~
機密的:confidential:~
TCP:
entropy::::エントロピー
drift:::同期ずれ
縛られ:tieされ:~
分別-:differentiate:~
	より低い層:lower-layer
濫用:abuse:~
抑制:reduction:~
process::::プロセス
無関係な:unrelatedな:~
推定-:infer:~
決定的:critical:~
	~~基盤:primitives
	側からの:side channel
	可能にする:enables
	につながる:associated
	-:total
	安全でない:unsafe

	●仕様
生粋:genuine:純粋
助け:help:~
未解決:unsolved:~
発展途上な:evolve している:~
	:evolving
事実調査:research:~
分野:area:~
産業界:industry:~
業界:industry:~
総意:consensus:~
権威ある:definitiveな:~
満足され:satisfyされ:満たされ
捕える:catchする:~
歪めら:distortさ:~
無用:useless:~
関心:interest:~
完璧:perfect:~
統一-:unify:~
推測-:guess:~
処する:dealする:~
特質:property:~

	実施~上の:practical
	アリでない:impossible
	~~可能性がある:potentially
	にもなり得る:potential
	選ぶ:choose
	義務付けるもの:mandatory part of
	化す:render
	事実:fact
	起因-:stem
	周りで:revolves around
	〜を~~自前で:in-the-wild
	早期:early
	〜にとって〜が問われる:talk
	次に挙げるもの:a few different
	大きな:major
	依拠-可能でない:unreliable
	比較-可能:comparable
	-:equivalently
	べき:ought

	●未分類
unload:
換算-:translate:~
交換-:exchange:~
近しい:familiarな:~
typedef:
toJSON:
cue:
到着-:arrive:~

	集めて:gather
	文書~navi:navigating to a Document
	~~背後に回され:backgrounded
	量:amount
	point
	using
	-:assert
	基準:with respect to
	across
	incognito
	過去現在未来:past, present, and future,
	より長い:longer
	:in place#1
	against
	変わり:vary
	常に:for any time
	以前:previously
	, :both
	最後に:finally
	短い:short
	含む:includeする
	選び取れ:pick
	どちらの~momentも:Neither endpoint
	近く:close
	ときどき:sometimes
	ときには:sometimes
	“~group”:settings-objects-that-could-possibly-communicate
	^en:reference point
	失われ:lose


●●ref_normative

[dom]
    ＜DOM Standard＞. Anne van Kesteren.  WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMA-262]
    ＜ECMAScript Language Specification＞.  Ecma International. URL: https://tc39.es/ecma262/multipage/
[html]
    ＜HTML Standard＞.
 Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; 
Philip Jägenstedt; Simon Pieters.  WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
    ＜Infra Standard＞. Anne van Kesteren; Domenic Denicola.  WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
    ＜Key words for use in RFCs to Indicate Requirement Levels＞. S. Bradner.  IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
    ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞. B. Leiba.  IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[SPECTRE]
    ＜Spectre Attacks: Exploiting Speculative Execution＞.
 Paul Kocher; Jann Horn; Anders Fogh; Daniel Genkin; Daniel Gruss; 
Werner Haas; Mike Hamburg; Moritz Lipp; Stefan Mangard; Thomas Prescher;
 Michael Schwarz; Yuval Yarom. January 2018. URL: https://spectreattack.com/spectre.pdf
[Temporal]
    ＜Temporal＞.  ECMA TC39. Stage 3 Proposal. URL: https://tc39.es/proposal-temporal/
[WEBIDL]
    ＜Web IDL Standard＞. Edgar Chen; Timothy Gu.  WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

●●ref_informative

[CACHE-ATTACKS]
    ＜The Spy in the Sandbox - Practical Cache Attacks in Javascript＞. Yossef Oren; Vasileios P. Kemerlis; Simha Sethumadhavan; Angelos D. Keromytis. 1 March 2015. URL: https://arxiv.org/abs/1502.07373
[reporting]
    ＜Reporting API＞. Douglas Creager; Ian Clelland; Mike West.  W3C. 13 August 2024. W3C Working Draft. URL: https://www.w3.org/TR/reporting-1/
[service-workers]
    ＜Service Workers＞. Jake Archibald; Marijn Kruisselbrink.  W3C. 12 July 2022. W3C Candidate Recommendation. URL: https://www.w3.org/TR/service-workers/


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより
編集者草案として公開された
<a href="~SPEC_URL">High Resolution Time</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/hr-time-3/
公表履歴
	https://www.w3.org/standards/history/hr-time-3/
編集者草案
	https://w3c.github.io/hr-time/
commit 履歴
	https://github.com/w3c/hr-time/commits/

テスト一式
	https://wpt.live/hr-time/
実装報告
	https://wpt.fyi/hr-time/

編集
	<a href="https://blog.yoav.ws/">Yoav Weiss</a> (Google LLC)
前任編集者
	<a href="mailto:igrgiroik@gmail.com">Ilya Grigorik</a> (Google LLC) - Until 01 March 2021
	<a href="mailto:simonjam@google.com">James Simonsen</a> (Google LLC) - Until 01 January 2015
	<a href="mailto:jmann@microsoft.com">Jatinder Mann</a> (Microsoft Corp.) - Until 01 February 2014

フィードバック
	<a href="https://github.com/w3c/hr-time/">GitHub w3c/hr-time</a> (<a href="https://github.com/w3c/hr-time/pulls/">pull requests</a>, <a href="https://github.com/w3c/hr-time/issues/new/choose">new issue</a>, <a href="https://github.com/w3c/hr-time/issues/">open issues</a>)

ブラウザサポート
	https://caniuse.com/high-resolution-time
公表者
	<a href="https://www.w3.org/groups/wg/webperf">Web Performance WG</a>
</script>

</head>
<body>

<header>

	<hgroup>
<h1>高分解能な時刻 — High Resolution Time</h1>
	</hgroup>

</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p>
この仕様は、
分解能が~milli秒より細かい（ `sub-millisecond^en ）†, かつ
`外的な時計~調整$の~subjectにされない［
`時刻~起点$enV／現在の時刻
］を供する~APIを定義する。
【†`具体的な精度は決まっていない＠#desired-resolution$。】
◎
This specification defines an API that provides the time origin, and current time in sub-millisecond resolution, such that it is not subject to system clock skew or adjustments.
</p>

	</section>
	<section id="sotd">
◎位置付け

<p>
この節では、
公表~時点における…
【以下、この節の内容は，~SOTD-W3Cに移譲。】
</p>

	</section>

<main id="MAIN0">

	<section id="_conventions">
<h2>【この訳に特有な表記規約】</h2>

◎表記記号

<p>
`外的な時計~調整@
とは、
原文における［
“`system clock adjustments^en”,
“`clock adjustments^en”,
“`system clock skew^en”,
“`clock skew^en”
］の総称である
（この仕様が定義する~modelにおいては、
これらを区別する必要はないので）。
原文には説明されていないが、
`system clock adjustments^en は、
NTP などの外部の基準~時計と~system時計とのずれを
— 自動的に，場合によっては利用者が —
調整することを意味するようだ。
`clock skew^en は、
Wikipedia によれば［
熱などの物理的な要因／回路構成などの機械的な要因
］による，~system内の複数箇所の間の~driftを意味するようだが、
この語の用法から，それに対処するために~system時計を調整することを表すと見受けられる。
</p>

<p>
この仕様にて以前に定義されていた用語
`時刻~起点＠#dfn-time-origin@
（ `time origin^en ）は、
今や，~HTMLに定義される`時刻~起点$enVを参照する。
</p>

	</section>
	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

◎非規範的

<p>
ECMAScript 言語~仕様 `ECMA-262$r は、［
`~Unix~epoch$【！01 January, 1970 UTC】からの~milli秒数による時間
］を表現する時刻~値として，
`Date$c ~objを定義する。
この値は，［
`~Unix~epoch$【！01 January, 1970 UTC】から約 285616 年間まで
］の どの時刻も~milli秒数で表現できる
— ほとんどの目的においては、
この定義で足りる。
◎
The ECMAScript Language specification [ECMA-262] defines the Date object as a time value representing time in milliseconds since 01 January, 1970 UTC. For most purposes, this definition of time is sufficient as these values represent time to millisecond precision for any moment that is within approximately 285,616 years from 01 January, 1970 UTC.
</p>

<p>
これらの定義による時刻は、
実施においては，`外的な時計~調整$の~subjectにもなる。
時刻~値は常に単調増加するとは限らず，後続な値は減少したり, 同じままになることもある。
◎
In practice, these definitions of time are subject to both clock skew and adjustment of the system clock. The value of time may not always be monotonically increasing and subsequent values may either decrease or remain the same.
</p>

<div class="example">
<p>
例えば 次の~scriptは、
%duration の計算結果として［
正な値, 負な値, 0
］いずれも記録し得る。
◎
For example, the following script may record a positive number, negative number, or zero for computed duration:
◎
Example 1
</p>

<pre class="lang-js">
var %mark_start = Date.now();
doTask(); // <span class="comment">何らかの~task</span>
var %duration = Date.now() - %mark_start;
</pre>

</div>

<p>
この定義による時刻は、
ある種の~taskには不足になろう
— ［
安定的な`単調増加~時計$を成さず，`外的な時計~調整$の~subjectになる／
~milli秒より細かい分解能を供さない
］ので。
◎
For certain tasks this definition of time may not be sufficient as it:
• Does not have a stable monotonic clock, and as a result, it is subject to system clock skew.
• Does not provide sub-millisecond time resolution.
</p>

<p>
この仕様は、
`Date.now()$c `ECMA-262$r の挙動を変更するよう提案するものではない。
それは、［
暦における現在の時刻~値を決定すること
］においては生粋に有用であり，長い利用の歴史がある。
上に挙げた課題は、
`DOMHighResTimeStamp$I 型と `Performance$I の［
`now()$m  ~method／
`timeOrigin$m 属性
］が［
単調増加する, 分解能が~milli秒より細かい時刻~値
］を供することにより，解決される。
◎
This specification does not propose changing the behavior of Date.now() [ECMA-262] as it is genuinely useful in determining the current value of the calendar time and has a long history of usage. The DOMHighResTimeStamp type, Performance.now() method, and Performance.timeOrigin attributes of the Performance interface resolve the above issues by providing monotonically increasing time values with sub-millisecond resolution.
</p>

<p class="note">注記：
この仕様は、
~milli秒より細かい分解能を供するよう，義務付けるものではない。
~privacyと~securityの理由から，実装は、
自身が公開する~timerの分解能を制限して，~milli秒より細かい~timerは公開しないことにしてもヨイ。
それが起きた下では、
~milli秒より細かい分解能に依拠する利用事例は，満足されないであろう。
◎
Note

Providing sub-millisecond resolution is not a mandatory part of this specification. Implementations may choose to limit the timer resolution they expose for privacy and security reasons, and not expose sub-millisecond timers. Use-cases that rely on sub-millisecond resolution may not be satisfied when that happens.
</p>

		<section id="use-cases">
<h3 title="Use-cases">1.1. 利用事例</h3>

◎非規範的

<p>
この仕様は、
次に挙げる能力を伴う時計を定義して，それに基づいて時刻印を供する
⇒＃
安定的に単調増加する,
異なる文脈で比較-可能,
~milli秒より細かい分解能にもなり得る
◎
This specification defines a few different capabilities: it provides timestamps based on a stable, monotonic clock, comparable across contexts, with potential sub-millisecond resolution.
</p>

<p>
処理能の測定において，安定的に単調増加する時計の必要性が問われるのは、
当の測定が無関係な`外的な時計~調整$により歪められ，無用と化す事実があることに起因する。
例えば，［
文書~navi, 資源の~fetching, ~scriptの実行
］などに費やされた時間を正確aに測定しようと試みるとき、
単調増加する, かつ分解能が~milli秒より細かい時計が欲される。
◎
The need for a stable monotonic clock when talking about performance measurements stems from the fact that unrelated clock skew can distort measurements and render them useless. For example, when attempting to accurately measure the elapsed time of navigating to a Document, fetching of resources or execution of script, a monotonically increasing clock with sub-millisecond resolution is desired.
</p>

<p>
異なる文脈で得られた時刻印を比較することは、
例えば，次のときに本質的になる
⇒＃
`Worker$I と~main~threadの間で作業を同期するとき／
そのような作業を計測して，~event時列線の統一された~viewを作成するとき
◎
Comparing timestamps between contexts is essential e.g. when synchronizing work between a Worker and the main thread or when instrumenting such work in order to create a unified view of the event timeline.
</p>

<p>
最後に，~milli秒より細かい~timerは、
次に挙げる利用事例の周りで必要になる：
◎
Finally, the need for sub-millisecond timers revolves around the following use-cases:
</p>
<ul>
	<li>
~milli秒より細かい周期で作業を~scheduleする能。
それは、
利用者から可視になるカクつきを避けるため，特に~main~threadで重要になる
— そこでの作業は、［
短い周期で定期的に起きる必要がある，~frameの描画
］に干渉し得る。
◎
Ability to schedule work in sub-millisecond intervals. That is particularly important on the main thread, where work can interfere with frame rendering which needs to happen in short and regular intervals, to avoid user-visible jank.
</li>
	<li>
~scriptに基づく~animationの~frame~rateを計算するとき、
~animationが 60 FPS で描画されているかどうか決定するためには，~milli秒より細かい分解能が必要になる。
~milli秒より細かくなければ、
開発者は 58.8 FPS と 62.5 FPS を区別するのが限界になる（ 1 ~frameあたり前者が 1/58.8 = 約 0.017 秒, 後者は 0.016 秒）。
◎
When calculating the frame rate of a script-based animation, developers will need sub-millisecond resolution in order to determine if an animation is drawing at 60 FPS. Without sub-millisecond resolution, a developer can only determine if an animation is drawing at 58.8 FPS (1000ms / 16) or 62.5 FPS (1000ms / 17).
</li>
	<li>
開発者は，~JS~codeの測定を~~自前で収集するとき（例： `User Timing$cite を利用して）、
自身の関数に対し~milli秒より細かい計時を集めて，退歩を早期に捕えることにも関心があろう。
◎
When collecting in-the-wild measurements of JS code (e.g. using User-Timing), developers may be interested in gathering sub-milliseconds timing of their functions, to catch regressions early.
</li>
	<li>
~animation内の特定の時点に音声を~cueしようと試みるときや,
音声と~animationが完璧に同期するのを確保するためには、
開発者は，時間の~~長さを正確aに測定する必要がある。
◎
When attempting to cue audio to a specific point in an animation or ensure that the audio and animation are perfectly synchronized, developers will need to accurately measure the amount of time elapsed.
</li>
</ul>

		</section>
		<section id="examples">
<h3 title="Examples">1.2. 例</h3>

◎非規範的

<p>
開発者は、
自身の~app全体にわたり，`時刻~起点$enVが異なる［
`Worker$I や `SharedWorker$I
］からの~eventも含むような時列線†を構築したいと望むこともあろう。
`timeOrigin$m 属性の助けを借りて 各~eventの `DOMHighResTimeStamp$I 値を換算すれば、
~appは，そのような~eventたちを同じ時列線~上に表示できる。
◎
A developer may wish to construct a timeline of their entire application, including events from Worker or SharedWorker, which have different time origins. To display such events on the same timeline, the application can translate the DOMHighResTimeStamps with the help of the Performance.timeOrigin attribute.
</p>

<p class="trans-note">【†
時列線（ `timeline^en ）
— 生じた~eventをその時刻とともに時系列順に記録するもの
（無数の時刻~値からなる並びが成す線）。
】</p>

<div class="example">

<pre class="lang-js">
// ---- worker.js -----------------------------
/* <span class="comment">
`SharedWorker$I 内の~script
◎
Shared worker script
</span> */
onconnect = function(%e) {
  var %port = %e.ports[0];
  %port.onmessage = function(%e) {
    /* <span class="comment">
~worker内での計時~task
◎
Time execution in worker
</span> */
    var %task_start = performance.now();
    %result = runSomeWorkerTask();
    var %task_end = performance.now();
  }

  /* <span class="comment">
結果と, および~epochに相対的な時刻【！timestamp】を，別の文脈へ送信する
◎
Send results and epoch-relative timestamps to another context
</span> */
  %port.postMessage({
     'task': 'Some worker task',
     'start_time': %task_start + performance.timeOrigin,
     'end_time': %task_end + performance.timeOrigin,
     'result': %result
  });
}

// ---- application.js ------------------------
/* <span class="comment">
文書~内での計時~task
◎
Timing tasks in the document
</span> */
var %task_start = performance.now();
runSomeApplicationTask();
var %task_end = performance.now();

/* <span class="comment">
稼働時の処理能~dataを~uploadするために開発者が供した~method
◎
developer provided method to upload runtime performance data
</span> */
reportEventToAnalytics({
  'task': 'Some document task',
  'start_time': %task_start,
  'duration': %task_end - %task_start
});

/* <span class="comment">
~workerの時刻印を文書の`時刻~起点$enVに換算する
◎
Translating worker timestamps into document's time origin
</span> */
var %worker = new SharedWorker('worker.js');
%worker.port.onmessage = function (%event) {
  var %msg = %event.data;

  /* <span class="comment">
~epochに相対的な時刻【！timestamp】を文書の`時刻~起点$enVに換算する
◎
translate epoch-relative timestamps into document's time origin
</span> */
  %msg.start_time = %msg.start_time - performance.timeOrigin;
  %msg.end_time = %msg.end_time - performance.timeOrigin;

  reportEventToAnalytics(%msg);
}
</pre>

</div>

		</section>
	</section>
	<section id="sec-concepts">
<h2 title="Time Concepts">2. 時間（時刻）の概念</h2>

		<section id="sec-clocks">
<h3 title="Clocks">2.1. 時計</h3>

<p>
`時計@
（ `clock^en ）は、
時間の経過を追跡する
— すなわち、［
ある~algoにて，ある段を実行している時点
］における時刻を
`安全でない現在の時刻@
（ `unsafe current time^en ）として報告できる。
◎
A clock tracks the passage of time and can report the unsafe current time that an algorithm step is executing.＼
</p>

<p class="trans-note">【
“安全でない” と称される理由は、
`§ ~securityの考慮点＠#sec-security$を見よ。
】</p>

<p>
時計には，多くの種類がある。
~web~platformにおける`時計$は，どれも［
現実世界の時間を成す 1 ~milli秒ごとに，時計~時間を成す 1 ~milli秒を数える
］よう試みるが、
それらは，［
正確に正しくなれない事例を各自が どう取扱うか
］において相違する。
◎
There are many kinds of clocks. All clocks on the web platform attempt to count 1 millisecond of clock time per 1 millisecond of real-world time, but they differ in how they handle cases where they can't be exactly correct.
</p>

<p>
`時計$は、
`壁~時計@
（ `wall clock^en ）,
`単調増加~時計@
（ `monotonic clock^en ）
に大別される：
◎
↓</p>
<ul>
	<li>
<p>
`壁~時計の安全でない現在の時刻@
— `壁~時計$から得られる`安全でない現在の時刻$ —
は、
常に，アリな限り利用者の［
時間の観念
］に近くあろうとする。
~computerは，ときには［
時間が早くまたは遅く流れる／
時間を追跡できなくなる
］ので、
`壁~時計$は，ときどき調整される必要がある
— このことは、
`壁~時計の安全でない現在の時刻$は減少し得ること，したがって［
処理能を測定する／~eventたちの順序を記録する
］用途においては依拠-可能にならないことを意味する。
◎
The wall clock's unsafe current time is always as close as possible to a user's notion of time. Since a computer sometimes runs slow or fast or loses track of time, its wall clock sometimes needs to be adjusted, which means the unsafe current time can decrease, making it unreliable for performance measurement or recording the orders of events.＼
</p>

<p>
~web~platformは、
`壁~時計$を
`~JS時刻@
— `ECMA-262$r に定義される`時刻＠~TC39#sec-time-values-and-time-range$ —
と共有する。
◎
The web platform shares a wall clock with [ECMA-262] time.
</p>

<p class="trans-note">【
単に “時刻（ `time^en ）” では汎用に過ぎるので、
この訳では， “~JS時刻” と称することにする。
】</p>
	</li>
	<li>
<p>
`単調増加~時計の安全でない現在の時刻@
— `単調増加~時計$から得られる`安全でない現在の時刻$ —
は、
決して減少しないので，`外的な時計~調整$により変更され得ない。
`単調増加~時計$は，`~UA$の［
1 回の実行
］の中に限り存在するので、［
互いに異なる実行にて起こるかもしれない~event
］どうしを比較するときには，利用できない。
◎
The monotonic clock's unsafe current time never decreases, so it can't be changed by system clock adjustments. The monotonic clock only exists within a single execution of the user agent, so it can't be used to compare events that might happen in different executions.
</p>

<p class="note">注記：
`単調増加~時計$は，利用者の［
時間の観念
］に合致するよう調整し得ないので、
利用者から可視な時間ではなく，測定~用に利用するベキである。
利用者に通信する用途には、
常に壁~時計を利用すること。
◎
Note

Since the monotonic clock can't be adjusted to match the user's notion of time, it should be used for measurement, rather than user-visible times. For any time communication with the user, use the wall clock.
</p>

<p class="note">注記：
~UAは、［
~browserの各~再起動 ／
他から隔離された閲覧~session（例：~~私的（ `incognito or similar^en ）閲覧~mode）の各~開始／
既存の どの設定群~objとも通信し得ない`環境~設定群~obj$を作成する各~回
］ごとに，新たな［
`単調増加~時計において~Unix~epochを成すものと見積もられる時刻$
］を選び取れる。
そのため，開発者は、［［
過去現在未来すべての文脈にわたって単調増加する特質
］を保持する，絶対的な時刻
］には，共有される時刻印を利用するベキでない
【すなわち、ある回で`単調増加~時計$から得られた時刻印を他の回に再利用するベキでない】。
実施において，単調増加する特質を適用できる用途は、［
供された~message法の仕組み
— 例： `postMessage(message, options)$m, `BroadcastChannel$I, 等々 —
を介して~messageを交換することにより，互いに他へ到達できるような文脈
］に限られる。
◎
Note

The user agent can pick a new estimated monotonic time of the Unix epoch when the browser restarts, when it starts an isolated browsing session—e.g. incognito or a similar browsing mode—or when it creates an environment settings object that can't communicate with any existing settings objects. As a result, developers should not use shared timestamps as absolute time that holds its monotonic properties across all past, present, and future contexts; in practice, the monotonic properties only apply for contexts that can reach each other by exchanging messages via one of the provided messaging mechanisms - e.g. postMessage(message, options), BroadcastChannel, etc.
</p>

<p class="note">注記：
ある種の局面においては
（例：~UItabが~~背後に回されているとき）、
~UAは，その文脈においては［
~callbackを周期的に走らす~~頻度を抑えるよう，~timerを絞ることを
— あるいは、まるごと凍結することさえ —
選ぶ
］こともあろう。
そのようにしたときでも、
`単調増加~時計$が返す時刻の分解能や正確aさには影響するベキでない。
◎
Note

In certain scenarios (e.g. when a tab is backgrounded), the user agent may choose to throttle timers and periodic callbacks run in that context or even freeze them entirely. Any such throttling should not affect the resolution or accuracy of the time returned by the monotonic clock.
</p>
	</li>
</ul>

		</section>
		<section id="moments-and-durations">
<h3 title="Moments and Durations">2.2. ~momentと所要時間</h3>

<p>
各`時計$の`安全でない現在の時刻$は、
`安全でない~moment@
（ `unsafe moment^en ）を返す。
`時刻を粗化する$ことは、
これら`安全でない~moment$を
`粗化した~moment@
（ `coarsened moment^en ）
— 略して`~moment$ —
に変換する。
◎
Each clock's unsafe current time returns an unsafe moment. Coarsen time converts these unsafe moments to coarsened moments or just moments.＼
</p>

<p class="note">注記：
［
`~moment$／`安全でない~moment$
］は、［
時間における一点
］を表現する
— それは、
直に数として格納し得ないことを意味する。
実装は、
通例的に，`~moment$を他の何らかの固定的な［
時間における一点
］からの`所要時間$として表現することになるが、
仕様は，`~moment$それ自体で処するべきである。
◎
Note

Moments and unsafe moments represent points in time, which means they can't be directly stored as numbers. Implementations will usually represent a moment as a duration from some other fixed point in time, but specifications ought to deal in the moments themselves.
</p>

<p class="trans-note">【
この仕様の文脈において “`moment^en” に相応しい対訳は，
“~~時刻” くらいしか思いつかないが、
それは，すでに `time^en の対訳として利用されている。
“~~時点” とも訳せるが、
それも，至る所で `time^en その他の対訳に利用されている。
（ `time^en は、
通例的に，文脈に依存して［
“~~時間” ／ “~~時刻”
］と訳されるが、
その訳し分けが，この仕様における［
`duration^en ／ `moment^en
］の概念に いくぶん対応する。）
】</p>

<p>
異なる時計から得られた［
`安全でない~moment$／`~moment$
］どうしは、
比較-可能でない。
◎
Unsafe moments and moments from different clocks are not comparable.
</p>

<p>
`所要時間@
（ `duration^en ）は、
同じ`時計$から得られた［
ある`~moment$から別の`~moment$まで
］の距離である
— ［
すべての`所要時間$が
`§ 時計の分解能＠#clock-resolution$における懸念を軽減する
］ことを確保するため、
どちらの`~moment$も`安全でない~moment$にし得ない。
`所要時間$は、［
~milli秒数, 秒数, 等々
］で測定される。
すべての`時計$は，同じ~rateで数えるよう試みるので、
`所要時間$に結付けられる`時計$は無い。
◎
A duration is the distance from one moment to another from the same clock. Neither endpoint can be an unsafe moment so that both durations and differences of durations mitigate the concerns in 9.1 Clock resolution. Durations are measured in milliseconds, seconds, etc. Since all clocks attempt to count at the same rate, durations don't have an associated clock,＼
</p>

<p class="trans-note">【
この仕様に現れる “相対的な時刻” は、
実質的に，所要時間の同義語と見なせる。
】</p>

<p>
ある`時計$ %時計 から得られた`~moment$に対しては、［
ある【%時計 とは同じと限らない】`時計$から得られた 2 個の`~moment$
］から計算された`所要時間$を加算して，
%時計 における別の`~moment$を生産できる。
◎
and a duration calculated from two moments on one clock can be added to a moment from a second clock, to produce another moment on that second clock.
</p>

<div class="algo">
<p>
`所要時間を得る@
~algoは、
所与の
( `~moment$ %a, `~moment$ %b )
に対し：
◎
The duration from a to b is the result of the following algorithm:
</p>
<ol>
	<li>
~Assert：
%a, %b は、
同じ`時計$から得られた【！created by】。
◎
Assert: a was created by the same clock as b.
◎
↑↑ Assert: Both a and b are coarsened moments.
</li>
	<li>
<p>
~RET %a から %b までの時間の量を成す`所要時間$
◎
Return the amount of time from a to b as a duration.＼
</p>

<p>
これは、
%b が %a より~~過去を指すならば，負になる。
◎
If b came before a, this will be a negative duration.
</p>
	</li>
</ol>

<p class="trans-note">【
%a, %b どちらかが`安全でない~moment$である場合，
この~algoは利用できないので、
その場合に “所要時間” を得る必要がある所では，単に
“%a から %b までの所要時間”
の様に述べることになる。
（原文の~algo名は，素直に訳すと同じ
“〜から〜までの所要時間”
の様な形になるが、
そうすると判別し難くなるので，
この訳では “所要時間を得る” に改める。）
】</p>

</div>

<p>
`所要時間$は、
暗黙的に `DOMHighResTimeStamp$I として利用できる
— `所要時間を時刻印に暗黙的に変換する$ことにより。
◎
Durations can be used implicitly as DOMHighResTimeStamps.＼
</p>

<div class="algo">
<p>
`所要時間を時刻印に暗黙的に変換する@
~algoは、
所与の
( `所要時間$ %d )
に対し
⇒
~RET %d を成す~milli秒数
</p>
◎
To implicitly convert a duration to a timestamp, given a duration d, return the number of milliseconds in d.
</div>

		</section>
	</section>
	<section id="sec-tools">
<h2 title="Tools for Specification Authors">3. 仕様~策定者~用の~tool</h2>

<p>
単独の~page
— `環境~設定群~obj$の文脈 —
の中で時間を測定する用途には、
`現在の相対的な時刻印$を利用すること。
◎
For measuring time within a single page (within the context of a single environment settings object), use the settingsObject's current relative timestamp,＼
</p>

<div class="algo">
<p>
`現在の相対的な時刻印@
を得る
~algoは、
所与の
( `環境~設定群~obj$ %設定群~obj )
に対し，`所要時間$を返す
⇒
~RET `所要時間を得る$( %設定群~obj の`時刻~起点$enV, %設定群~obj の`現在の単調増加~時計~時刻$ )
◎
defined as the duration from settingsObject's time origin to the settingsObject's current monotonic time.＼
</p>
</div>

<p>
`現在の相対的な時刻印$は、
`所要時間を時刻印に暗黙的に変換する$ことにより，
`DOMHighResTimeStamp$I として~JSに直に公開され得る。
◎
This value can be exposed directly to JavaScript using the duration's implicit conversion to DOMHighResTimeStamp.
</p>

<p>
`環境~設定群~obj$の`時刻~起点$enVが比較~用の基底として適切でないときに，
単独の~UA実行の中で時間を測定する用途には、
`現在の単調増加~時計~時刻$を利用して，`~moment$を作成すること。
◎
For measuring time within a single UA execution when an environment settings object's time origin isn't an appropriate base for comparison, create moments using an environment settings object's current monotonic time.＼
</p>

<div class="algo">
<p>
`現在の単調増加~時計~時刻@
を得る
~algoは、
所与の
( `環境~設定群~obj$ %設定群~obj )
に対し，`~moment$を返す：
◎
An environment settings object settingsObject's current monotonic time is the result of the following steps:
</p>
<ol>
	<li>
%安全でない単調増加~時計~時刻 ~LET `単調増加~時計の安全でない現在の時刻$
◎
Let unsafeMonotonicTime be the monotonic clock's unsafe current time.
</li>
	<li>
~RET `時刻を粗化する$( %安全でない単調増加~時計~時刻, %設定群~obj の`非同一-生成元~能力は隔離されるか？$enV )
◎
Return the result of calling coarsen time with unsafeMonotonicTime and settingsObject's cross-origin isolated capability.
</li>
</ol>
</div>

<p>
`単調増加~時計$から得られた`~moment$は、［
~JS／~HTTP
］においては，直に表現できない。
代わりに、
そのような 2 個の`~moment$の間の`所要時間$を公開すること。
◎
Moments from the monotonic clock can't be directly represented in JavaScript or HTTP. Instead, expose a duration between two such moments.
</p>

<p>
複数回の~UA実行にまたがって時間を測定する用途には、
次のいずれかを利用して`~moment$を作成すること：
◎
For measuring time across multiple UA executions,＼
</p>
<ul>
	<li>
`粗化した現在の壁~時計~時刻$
◎
create moments using the current coarsened wall time
</li>
	<li>
［
`環境~設定群~obj$ %設定群 の`非同一-生成元~能力は隔離されるか？$enV ~EQ ~T
］のときに，より高い精度が必要になる場合には、
`現在の壁~時計~時刻$enV( %設定群 )
◎
or (if you need higher precision in cross-origin-isolated contexts) an environment settings object's current wall time.＼
</li>
</ul>

<div class="algo">
`粗化した現在の壁~時計~時刻@
を得る
~algoは、
`~moment$を返す
⇒
~RET `時刻を粗化する$( `壁~時計の安全でない現在の時刻$ )
◎
The current coarsened wall time is the result of calling coarsen time with the wall clock's unsafe current time.
</div>

<div class="algo">
`現在の壁~時計~時刻@enV
を得る
~algoは、
所与の
( `環境~設定群~obj$ %設定群 )
に対し，`~moment$を返す
⇒
~RET `時刻を粗化する$( `壁~時計の安全でない現在の時刻$, %設定群 の`非同一-生成元~能力は隔離されるか？$enV )
◎
An environment settings object settingsObject's current wall time is the result of the following steps:
• Let unsafeWallTime be the wall clock's unsafe current time.
• Return the result of calling coarsen time with unsafeWallTime and settingsObject's cross-origin isolated capability.
</div>

<p class="advisement">
`壁~時計$から得られた`~moment$を利用しているときは、
利用者による`外的な時計~調整$も織り込むよう設計すること。
◎
When using moments from the wall clock, be sure that your design accounts for situations when the user adjusts their clock either forward or backward.
</p>

<p>
`壁~時計$から得られた`~moment$ %~moment は、
~JSにおいては，［
`Date$c ／ `Temporal.Instant$c
］構築子に`~Unix~epoch$から %~moment までの［
~milli秒数／~nano秒数
］を渡すことにより表現できる。
◎
Moments from the wall clock can be represented in JavaScript by passing the number of milliseconds from the Unix epoch to that moment into the Date constructor, or by passing the number of nanoseconds from the Unix epoch to that moment into the Temporal.Instant constructor.
</p>

<p class="advisement tracking-vector">
【`壁~時計$から得られた`~moment$に】類似な表現を［
ある~computerから別の~computerへ送信する
］ことは、
避けること。
そうすると、
利用者による`外的な時計~調整$を公開することになり，
`追跡~行路$として利用され得るので。
代わりに，［
`単調増加~時計$から得られた2 個の`~moment$の間の`所要時間$を送信すること
］に類似な~approachを利用すること。
◎
Avoid sending similar representations between computers, as doing so will expose the user's clock skew, which is a tracking vector. Instead, use an approach similar to monotonic clock moments of sending a duration between two moments.
</p>

		<section id="sec-tools-examples">
<h3 title="Examples">3.1. 例</h3>

<div class="example" id="example-current-relative-timestamp">
<p>
~DOM~eventが起こる時刻は、
次を利用して報告できる：
◎
The time a DOM event happens can be reported using:
</p>
<ol>
	<li>
%~event の `timeStamp$m 属性 ~SET `現在の相対的な時刻印$( コレに`関連な設定群~obj$ )
◎
Initialize event's timeStamp attribute to this's relevant settings object's current relative timestamp.
</li>
</ol>
</div>

<div class="example" id="example-current-monotonic-time">
<p>
~error報告の齢は、
次を利用して算出できる：
◎
The age of an error report can be computed using:
</p>
<ol>
	<li>
%報告 の`時刻印$rP ~SET %設定群 の`現在の単調増加~時計~時刻$
◎
Initialize report's generation time to settings' current monotonic time.
</li>
</ol>

<p>
後で：
◎
Later:
</p>
<ol>
	<li>
%所要時間 ~LET `所要時間を得る$( %報告 の`時刻印$rP, %文脈 に`関連な設定群~obj$の`現在の単調増加~時計~時刻$ )
◎
↓</li>
	<li>
%~data[ `age^l ] ~SET %所要時間 を成す~milli秒数を最も近い整数に丸めた結果
◎
Let data be a map with the following key/value pairs:
• age
•• The number of milliseconds between report's generation time and context's relevant settings object's current monotonic time, rounded to the nearest integer.
• ...
</li>
</ol>
</div>

<div class="example" id="example-current-wall-time">
<p>
何日後かに失効する何か `X^i は、
次のように取扱える：
◎
Multi-day attribution report expirations can be handled as:
</p>
<ol>
	<li>
%~source ~LET 新たな `X ~source^i 構造体
— その
⇒＃
~source時刻 ~SET `現在の壁~時計~時刻$enV( %文脈 ),
有効期間 ~SET 所要時間~文字列を構文解析する( %入力[ `expiry^l ] )
◎
Let source be a new attribution source struct whose items are:
• ...
• source time
•• context's current wall time
• expiry
•• parse a duration string from value["expiry"]
</li>
</ol>

<p>
何日か後で：
◎
Days later:
</p>
<ol>
	<li>
~IF［
`現在の壁~時計~時刻$enV( %文脈 ) ~LT %~source の~source時刻 ~PLUS %~source の有効期間
］
⇒
`X 報告^i を送信する
◎
If context's current wall time is less than source's source time + source's expiry, send a report.
</li>
</ol>
</div>

		</section>
	</section>
	<section id="sec-time-origin">
<h2 title="Time Origin">4. 時刻~起点</h2>

<p>
`~Unix~epoch@
は、
`壁~時計$において
`1 January 1970 00:00:00 UTC^en
【 1970年 1月 1日, 午前 0時 0分 0秒】
に対応している`~moment$である。
◎
The Unix epoch is the moment on the wall clock corresponding to 1 January 1970 00:00:00 UTC.
</p>

<p>
各~group
— 場合によっては何らかの仕方で互いに通信し得る`環境~設定群~obj$たちが成す~group —
は、
`単調増加~時計において~Unix~epochを成すものと見積もられる時刻@
（ `estimated monotonic time of the Unix epoch^en ）を有する
— それは、
`単調増加~時計$における`~moment$である。
◎
Each group of environment settings objects that could possibly communicate in any way has an estimated monotonic time of the Unix epoch, an unsafe moment on the monotonic clock,＼
</p>

<p class="trans-note">【
この定義は、
~groupを成す`環境~設定群~obj$たちが同じ`単調増加~時計$を共有していることが前提にある。
】</p>

<div class="algo">
<p>
`単調増加~時計において~Unix~epochを成すものと見積もられる時刻$は、
次の手続きの結果に初期化される：
◎
whose value is initialized by the following steps:
</p>
<ol>
	<li>
%壁~時計~時刻 ~LET `壁~時計の安全でない現在の時刻$
◎
Let wall time be the wall clock's unsafe current time.
</li>
	<li>
%単調増加~時計~時刻 ~LET `単調増加~時計の安全でない現在の時刻$
◎
Let monotonic time be the monotonic clock's unsafe current time.
</li>
	<li>
%~epoch時刻 ~LET %単調増加~時計~時刻 ~MINUS ( `~Unix~epoch$から %壁~時計~時刻 までの所要時間 )
◎
Let epoch time be monotonic time - (wall time - Unix epoch)
</li>
	<li>
~RET `時刻を粗化する$( %~epoch時刻 )
◎
Initialize the estimated monotonic time of the Unix epoch to the result of calling coarsen time with epoch time.
</li>
</ol>

<p class="trans-note">【
いつ初期化されるかは、
この仕様には述べられていない。
】</p>

</div>

<p class="issue">
上の “~group” は、
もっときちんと指定される必要がある。
それは、
“`近しい$ものたち” に類似するが，
`Worker$I も含む。
◎
Issue 1

The above set of settings-objects-that-could-possibly-communicate needs to be specified better. It's similar to familiar with but includes Workers.
</p>

<p>
処理能の測定は、［
関連な`環境~設定群~obj$の初期化における早期における`~moment$
］からの`所要時間$を報告する。
この`~moment$は、
当の設定群~objの`時刻~起点$enVに格納される。
◎
Performance measurements report a duration from a moment early in the initialization of a relevant environment settings object. That moment is stored in that settings object's time origin.
</p>

<div class="algo">
<p>
`時刻~起点の時刻印を取得する@
~algoは、
所与の
( `大域~obj$ %G )
に対し，`所要時間$を返す：
◎
To get time origin timestamp, given a global object global, run the following steps, which return a duration:
</p>
<ol>
	<li>
%設定群 ~LET %G に`関連な設定群~obj$
◎
↓</li>
	<li>
<p>
%時刻~起点 ~LET %設定群 の`時刻~起点$enV
◎
Let timeOrigin be global's relevant settings object's time origin.
</p>

<p class="note">注記：
この値は、［
`Window$I 文脈においては，`~navi$が開始された時刻／
［
`Worker$I ／ `ServiceWorker$I
］文脈【！contents】においては，当の`~workerを走らせ$た時刻 
］を表現する。
◎
Note

In Window contexts, this value represents the time when navigation has started. In Worker and ServiceWorker contents, this value represent the time when the worker is run. [service-workers]
</p>
	</li>
	<li>
~RET `所要時間を得る$( `単調増加~時計において~Unix~epochを成すものと見積もられる時刻$, %時刻~起点 )
◎
Return the duration from the estimated monotonic time of the Unix epoch to timeOrigin.
</li>
</ol>

<p class="note">注記：
この~algoが返す値は、
近似的に［
`~Unix~epoch$から後に %G の`時刻~起点$enVが起きた時刻
］になる。
それは、［
`外的な時計~調整$の~subjectにならない`単調増加~時計$
］を基準に記録されるので，［
`Date.now()$c を当の時刻~起点に実行したときの結果
］と相違し得る。
◎
Note

The value returned by get time origin timestamp is approximately the time after the Unix epoch that global's time origin happened. It may differ from the value returned by Date.now() executed at the time origin, because the former is recorded with respect to a monotonic clock that is not subject to system and user clock adjustments, clock skew, and so on.
</p>
</div>

<div class="algo">
<p>
`時刻を粗化する@
~algoは、
所与の
( %時刻印, 真偽値 %非同一-生成元~能力は隔離されるか （省略時は ~F ） )
に対し，`~moment$を返す：
◎
The coarsen time algorithm, given an unsafe moment timestamp on some clock and an optional boolean crossOriginIsolatedCapability (default false), runs the following steps:
</p>
<ol>
	<li>
~Assert：
%時刻印 は何らかの`時計$から得られた`安全でない~moment$である。
◎
↑</li>
	<li>
%時間~分解能 ~LET %非同一-生成元~能力は隔離されるか に応じて
⇒＃
~F ならば `実装定義$な 100 ~micro秒 以上の値 ／
~T ならば `実装定義$な 5 ~micro秒 以上の値
◎
Let time resolution be 100 microseconds, or a higher implementation-defined value.
◎
If crossOriginIsolatedCapability is true, set time resolution to be 5 microseconds, or a higher implementation-defined value.
</li>
	<li>
<p>
%時刻印 ~SET %時刻印 を`実装定義$な方式で次に従うよう改変した結果
⇒
%時刻印 の分解能を %時間~分解能 より粗化した上で，
任意選択で ゆらぎも加える
</p>

<p class="trans-note">【
改変するとしても、
%時刻印 が`単調増加~時計$から得られた場合の結果は，
前回に呼出したときの結果より減少しないよう拘束されよう。
】</p>
◎
In an implementation-defined manner, coarsen and potentially jitter timestamp such that its resolution will not exceed time resolution.
</li>
	<li>
~RET %時刻印
◎
Return timestamp as a moment.
</li>
</ol>
</div>

<div class="algo">
<p>
`相対的な高分解能~時刻@
を得る
~algoは、
所与の
( %時刻, `大域~obj$rM %G )
に対し，`所要時間$を返す：
◎
The relative high resolution time given an unsafe moment from the monotonic clock time and a global object global, is the duration returned from the following steps:
</p>
<ol>
	<li>
~Assert：
%時刻 は`単調増加~時計$から得られた`安全でない~moment$である。
◎
↑</li>
	<li>
%粗い時刻 ~LET `時刻を粗化する$( %時刻, %G に`関連な設定群~obj$の`非同一-生成元~能力は隔離されるか？$enV )
◎
Let coarse time be the result of calling coarsen time with time and global's relevant settings object's cross-origin isolated capability.
</li>
	<li>
~RET `相対的な粗い高分解能~時刻$( %粗い時刻, %G )
◎
Return the relative high resolution coarse time for coarse time and global.
</li>
</ol>
</div>

<div class="algo">
<p>
`相対的な粗い高分解能~時刻@
を得る
~algoは、
所与の
( %粗い時刻, `大域~obj$rM %G )
に対し，`所要時間$を返す：
</p>
<ol>
	<li>
~Assert：
%粗い時刻 は`単調増加~時計$から得られた`~moment$である。
</li>
	<li>
~RET `所要時間を得る$( %G に`関連な設定群~obj$の`時刻~起点$enV, %粗い時刻 )
</li>
</ol>
◎
The relative high resolution coarse time given a moment from the monotonic clock coarseTime and a global object global, is the duration from global's relevant settings object's time origin to coarseTime.
</div>

<div class="algo">
<p>
`現在の高分解能~時刻@
を得る
~algoは、
所与の
( `大域~obj$ %G )
に対し，`所要時間$を返す：
</p>
<ol>
	<li>
%現在の時刻 ~LET `安全でない共有される現在の時刻$
</li>
	<li>
~RET `相対的な高分解能~時刻$( %現在の時刻, %G )
</li>
</ol>

<p class="trans-note">【
他の仕様は、
この手続きを %G を省略して呼出すことが多い
— その場合、
文脈から暗黙的に決定されることになる（例えば，~APIを定義する手続きの中から呼出された場合、
%G はコレに`関連な大域~obj$になろう）。
】</p>

◎
The current high resolution time given a global object current global must return the result of relative high resolution time given unsafe shared current time and current global.
</div>

<div class="algo">
<p>
`粗化した共有される現在の時刻@
を得る
~algoは、
所与の
( 真偽値 %非同一-生成元~能力は隔離されるか （省略時は ~F ） )
に対し，`~moment$を返す：
</p>
<ol>
	<li>
%現在の時刻 ~LET `安全でない共有される現在の時刻$
</li>
	<li>
~RET `時刻を粗化する$( %現在の時刻, %非同一-生成元~能力は隔離されるか )
</li>
</ol>
◎
The coarsened shared current time given an optional boolean crossOriginIsolatedCapability (default false), must return the result of calling coarsen time with the unsafe shared current time and crossOriginIsolatedCapability.
</div>

<div class="algo">
`安全でない共有される現在の時刻@
を得る
~algoは
⇒
~RET `単調増加~時計の安全でない現在の時刻$
◎
The unsafe shared current time must return the unsafe current time of the monotonic clock.
</div>

	</section>
	<section id="sec-domhighrestimestamp">
<h2 title="The DOMHighResTimeStamp typedef">5. `DOMHighResTimeStamp^I ~typedef</h2>

<p>
`DOMHighResTimeStamp$I 型は、
`所要時間$を~milli秒数として格納するために利用される。
それは、
文脈に依存する基底`~moment$
— `時刻~起点$enVや`~Unix~epoch$など —
から この`所要時間$を経た後の`~moment$を表現する。
◎
The DOMHighResTimeStamp type is used to store a duration in milliseconds. Depending on its context, it may represent the moment that is this duration after a base moment like a time origin or the Unix epoch.
</p>

<pre class="idl">
typedef `double$ `DOMHighResTimeStamp@I;
</pre>

<p id="desired-resolution">
`DOMHighResTimeStamp$I 値は、
~milli秒数による時間を［
測定には十分, かつ計時~攻撃は防止する
］正確aさで表現するベキである。
追加的な考慮点については、
`§ 時計の分解能＠#clock-resolution$
を見よ。
◎
A DOMHighResTimeStamp SHOULD represent a time in milliseconds accurate enough to allow measurement while preventing timing attacks - see 9.1 Clock resolution for additional considerations.
</p>

<p class="note">注記：
`DOMHighResTimeStamp$I は `double^c 型なので、
~epochに相対的な時刻
— `~Unix~epoch$から ある`~moment$までの~milli秒数 —
を ある有限な分解能でしか表現できない。
2023年内【この段落を書いた時点？】の`~moment$においては、
その分解能は，約 0.2 ~micro秒になる。
◎
A DOMHighResTimeStamp is a double, so it can only represent an epoch-relative time—the number of milliseconds from the Unix epoch to a moment—to a finite resolution. For moments in 2023, that resolution is approximately 0.2 microseconds.
</p>

	</section>
	<section id="the-epochtimestamp-typedef">
<h2 title="The EpochTimeStamp typedef">6. `EpochTimeStamp^I ~typedef</h2>

<pre class="idl">
typedef `unsigned long long$ `EpochTimeStamp@I;
</pre>

<p class="note">注記：
`EpochTimeStamp$I は、
旧来の~platform特能であり，以前まで `DOMTimeStamp^I として知られていた。
`EpochTimeStamp^I の利用は、
忌避される
— アリなときは、
代わりに `DOMHighResTimeStamp$I を利用すること。
◎
Note: Legacy platform feature

The use of EpochTimeStamp, known previously as DOMTimeStamp, is discouraged. Wherever possible use DOMHighResTimeStamp instead.
</p>

<p>
`EpochTimeStamp$I は、
`~Unix~epoch$から所与の［
`壁~時計$から得られた`~moment$
］までの［
閏秒を除外した，整数な~milli秒数
］を表現する。
この~milli秒数がどう解釈されるかは、
この型を利用する各~仕様が定義することになる。
◎
A EpochTimeStamp represents an integral number of milliseconds from the Unix epoch to a given moment on the wall clock, excluding leap seconds. Specifications that use this type define how the number of milliseconds are interpreted.
</p>

	</section>
	<section id="sec-performance">
<h2 title="The Performance interface">7. `Performance^I ~interface</h2>

<pre class="idl">
[`Exposed$=(Window,Worker)]
interface `Performance@I : `EventTarget$I {
    `DOMHighResTimeStamp$I `now()$m;
    readonly attribute `DOMHighResTimeStamp$I `timeOrigin$m;
    [`Default$] `object$ `toJSON()$m;
};
</pre>

<div class="algo" id="now-method">
`now()@m
~method手続きは、
次の結果を成す`所要時間$を~milli秒数で返す
⇒
`現在の高分解能~時刻$( コレに`関連な大域~obj$ )
`basic.any$test
`basic.any.worker$test
◎
7.1 now() method
◎
The now() method MUST return the number of milliseconds in the current high resolution time given this's relevant global object (a duration).
</div>

<p>
同じ`時刻~起点$enVを共有する `Performance$I ~objたちは、
`now()$m ~methodが返す時刻~値に，同じ`単調増加~時計$を利用するモノトスル。
◎
The time values returned when calling the now() method on Performance objects with the same time origin MUST use the same monotonic clock.＼
</p>

<p class="trans-note">【
どの `Performance$I ~objたちが同じ`時刻~起点$enVを共有するものとされるかは，
この仕様には述べられていないが、
`§ 時刻~起点＠#sec-time-origin$に述べられた課題が関係すると見受けられる。
】</p>

<p>
`Performance$I ~objの `now()$m ~methodが返す［
時系列順に記録された 2 つの時刻~値
］の差は、［
それらの時刻~値が同じ`時刻~起点$enVを有する†
］ならば，決して負にならないモノトスル。
`monotonic-clock.any$test
`monotonic-clock.any.worker$test
◎
The difference between any two chronologically recorded time values returned from the now() method MUST never be negative if the two time values have the same time origin.
</p>

<p class="trans-note">【†
この条件は必要なのか？
（単独の `Performance$I ~objは、
複数個の`時刻~起点$enVを利用し得るのか？）
】</p>

<div class="algo" id="timeorigin-attribute">
<p>
`timeOrigin@m
取得子~手続きは、
次の結果を成す`所要時間$を~milli秒数で返す
⇒
`時刻~起点の時刻印を取得する$( コレに`関連な大域~obj$ )
`timeOrigin$test
`window-worker-timeOrigin.window$test
◎
The timeOrigin attribute MUST return the number of milliseconds in the duration returned by get time origin timestamp for the relevant global object of this.
</p>

<p>
`timeOrigin$m が返す時刻~値には、［
`時刻~起点$enVたちにより共有される【？】同じ`単調増加~時計$であって，
その `reference point^en は`~JS時刻$なるもの【？】
］を利用するモノトスル
— `§ ~securityの考慮点＠#sec-security$
を見よ。
`test_cross_frame_start$test
◎
The time values returned when getting Performance.timeOrigin MUST use the same monotonic clock that is shared by time origins, and whose reference point is the [ECMA-262] time definition - see 9. Security Considerations.
</p>
</div>

<div class="algo" id="tojson-method">
`toJSON()@m
~method手続きは、
`既定の~toJSON手続き$ `WEBIDL$r で与えられる。
`performance-tojson$test
◎
7.3 toJSON() method
◎
When toJSON() is called, run [WEBIDL]'s default toJSON steps.
</div>

	</section>
	<section id="extensions-to-windoworworkerglobalscope-mixin">
<h2 title="Extensions to WindowOrWorkerGlobalScope mixin">8. `WindowOrWorkerGlobalScope^I ~mixinに対する拡張</h2>

<p id="the-performance-attribute">
`WindowOrWorkerGlobalScope$I の
`performance@m
属性は、
`大域~obj$rMから処理能に関係する［
属性, ~method
］への~accessを許容する。
◎
8.1 The performance attribute
◎
The performance attribute on the interface mixin WindowOrWorkerGlobalScope allows access to performance related attributes and methods from the global object.
</p>

<pre class="idl">
partial interface mixin `WindowOrWorkerGlobalScope$I {
    [`Replaceable$] readonly attribute `Performance$I `performance$m;
};
</pre>

	</section>
	<section id="sec-security">
<h2 title="and Security Considerations">9. ~securityの考慮点</h2>

		<section id="clock-resolution">
<h3 title="Clock resolution">9.1. 時計の分解能</h3>

<p>
正確aな計時~情報への~accessは、
測定と~schedule法の両~目的において，多くの~appに共通な要件である。
例えば，［
~animation, 音, その他の~page上の活動
］を協調して，より良い利用者~体験を供するためには、
高分解能な時間への~accessを要する。
類似に、
開発者は，測定により［
~codeの決定的な部位における処理能を追跡する, 退歩を検出する, 等々
］が可能になる。
◎
Access to accurate timing information, both for measurement and scheduling purposes, is a common requirement for many applications. For example, coordinating animations, sound, and other activity on the page requires access to high-resolution time to provide a good user experience. Similarly, measurement enables developers to track the performance of critical code components, detect regressions, and so on.
</p>

<p>
しかしながら，その同じ正確aな計時~情報への~accessは、
攻撃者が他では見たり~accessできない~dataを推測して推定するような，悪意的な攻撃~目的にも利用され得る。
例えば，［
~cache攻撃／
統計的な指紋収集（ `statistical fingerprinting^en ）／
CPU ~architectureに乗じる攻撃（ `micro-architectural attack^en ）
］は、
悪意的な~web~siteが［
利用者たちを分別する／
特定0の利用者を識別する／
同一-~process内の無関係な利用者~dataを露呈する
］ために［
~browserや~appから起動される様々な演算による，高分解能な計時~data
］を利用し得る所における，~privacyや~securityの懸念である
— さらなる背景0は、
`CACHE-ATTACKS$r, `SPECTRE$r を見よ。
◎
However, access to the same accurate timing information can sometimes be also used for malicious purposes by an attacker to guess and infer data that they can't see or access otherwise. For example, cache attacks, statistical fingerprinting and micro-architectural attacks are a privacy and security concern where a malicious web site may use high resolution timing data of various browser or application-initiated operations to differentiate between subset of users, identify a particular user or reveal unrelated but same-process user data - see [CACHE-ATTACKS] and [SPECTRE] for more background.
</p>

<p>
この仕様は、［
これまで `EpochTimeStamp$I として公開され可用であった~milli秒の分解能
］よりも正確aな［
より細かい時間~分解能を供する~API
］を定義する。
しかしながら，この新たな~APIがなくとも、
攻撃者は［
~~反復~実行と統計的な分析を通して，高分解能な見積もりを得する
］ことは可能である。
`timing-attack$test
◎
This specification defines an API that provides sub-millisecond time resolution, which is more accurate than the previously available millisecond resolution exposed by EpochTimeStamp. However, even without this new API an attacker may be able to obtain high-resolution estimates through repeat execution and statistical analysis.
</p>

<p>
新たな~APIにより，そのような攻撃の正確度や速度が有意に向上されないことを確保するため、
`DOMHighResTimeStamp$I 型の分解能は，攻撃を防止するに十分な正確aさに抑えるベキである。
◎
To ensure that the new API does not significantly improve the accuracy or speed of such attacks, the minimum resolution of the DOMHighResTimeStamp type should be inaccurate enough to prevent attacks.
</p>

<p>
~UAは、
~architectureや~softwareにおける拘束, その他の考慮点に因り，~privacyや~securityの懸念に取組むために必要yな所では、
`時刻を粗化する$ための処理~modelにおいて %時間~分解能 に設定する値をもっと高くする【すなわち粗化する】ベキである。
◎
Where necessary, the user agent should set higher resolution values to time resolution in coarsen time's processing model, to address privacy and security concerns due to architecture or software constraints, or other considerations.
</p>

<p>
~UAは、
そのような攻撃を軽減するために必要と判断される技法があれば，それを配備してもヨイ。
そのような技法の配備は、
次に挙げるものに基づいて変わり得る
⇒＃
~browserの~architecture,
利用者の機器,
内容,
内容が非同一-生成元な~dataを悪意的に読取る能,
その他の実施~上の考慮点
◎
In order to mitigate such attacks user agents may deploy any technique they deem necessary. Deployment of those techniques may vary based on the browser's architecture, the user's device, the content and its ability to maliciously read cross-origin data, or other practical considerations.
</p>

<p>
これらの技法には、
次も含まれよう
⇒＃
分解能の抑制／
ゆらぎを加える／
濫用を検出して~API~callを絞る
◎
These techniques may include:
• Resolution reduction.
• Added jitter.
• Abuse detection and/or API call throttling.
</p>

<p>
そのような計時~側からの攻撃を まるごと軽減することは、
実施~上はアリでない。
そのためには，［
すべての演算の実行~時間は［
機密的な情報の値に基づいて変わることはない
］ようにする
］か［
~appを［
時間に関係するあらゆる~~基盤
］（時計, ~timer, ~counter, 等々）から隔離する
］必要があるが、
どちらも，［［
~browser／~app
］開発者にとっての複階性
］および［
~appの［
処理能, 応答性
］に対する負な効果
］につながることに因り，実用的でない。
◎
Mitigating such timing side-channel attacks entirely is practically impossible: either all operations would have to execute in a time that does not vary based on the value of any confidential information, or the application would need to be isolated from any time-related primitives (clock, timers, counters, etc). Neither is practical due to the associated complexity for the browser and application developers and the associated negative effects on performance and responsiveness of applications.
</p>

<p class="note">注記：
時計の分解能は、
未解決かつ発展途上な事実調査の分野であり，すべての~browserに適用される既存の［
業界~総意／権威ある推奨
］は無い。
`課題 #79＠https://github.com/w3c/hr-time/issues/79$
にて，論点を追跡できる。
◎
Note

Clock resolution is an unsolved and evolving area of research, with no existing industry consensus or definitive set of recommendations that applies to all browsers. To track the discussion, refer to Issue 79.
</p>

		</section>
		<section id="clock-drift">
<h3 title="Clock drift">9.2. 時計の~drift</h3>

<p>
この仕様は、［
分解能が~milli秒より細かい`時刻~起点の時刻印$
］を供する~APIも定義する。
~APIには［
すべての~browser文脈にわたって共有されなければナラナイ，`単調増加~時計$
］が要求され，それを~appに公開する。
この時計は，物理的な時刻に縛られる必要はないが、
新たな［
利用者についての指紋収集-
］~entropyを公開するのを避けるため，`~JS時刻$を基準に設定することが推奨される。
~JS時刻は，すでに~appにより容易に得される一方で、
新たな論理-時計を公開するのは，新たな情報を供するに等しいので。
◎
This specification also defines an API that provides sub-millisecond time resolution of the zero time of the time origin, which requires and exposes a monotonic clock to the application, and that must be shared across all the browser contexts. The monotonic clock does not need to be tied to physical time, but is recommended to be set with respect to the [ECMA-262] definition of time to avoid exposing new fingerprint entropy about the user — e.g. this time can already be easily obtained by the application, whereas exposing a new logical clock provides new information.
</p>

<p>
しかしながら，上述した仕組みの下でも、
`単調増加~時計$は，
`時計の~drift＠https://en.wikipedia.org/wiki/Clock_drift$
（ `clock drift^en, “遅れ／進み” ）に関する分解能も供し得る。
今日の~appは、
同じ文脈の中の複数の時点で，［
従来の時計による時刻印, 単調増加~時計による時刻印
］を（順に， `Date.now()$c, `now()$m を介して）得てから，
それらの間の~drift
— 例えば`外的な時計~調整$に因るそれ —
を観測できる。
攻撃者はまた、［
`timeOrigin$m 属性により，`単調増加~時計$から報告される`時刻~起点$enV
］と［
従来の時計により，現在~見積もられる`時刻~起点$enV
］
（すなわち，［
`performance.timeOrigin^c
］と［
`Date.now()^c ~MINUS `performance.now()^c
］との差）
とを長時間にわたり比較して，
これらの時計どうしの~driftを観測できる~~可能性がある。
◎
However, even with the above mechanism in place, the monotonic clock may provide additional clock drift resolution. Today, the application can timestamp the time-of-day and monotonic time values (via Date.now() and now()) at multiple points within the same context and observe drift between them—e.g. due to automatic or user clock adjustments. With the timeOrigin attribute, the attacker can also compare the time origin, as reported by the monotonic clock, against the current time-of-day estimate of the time origin (i.e. the difference between performance.timeOrigin and Date.now() - performance.now()) and potentially observe clock drift between these clocks over a longer time period. 
</p>

<p class="trans-note">【
例えば暗号処理を考える。
その処理の重さ（計算量）に因る CPU 熱は、
`外的な時計~調整$（この事例では `clock skew^en ）をもたらす結果，時計の~driftに反映され得る。
攻撃者は、
いくつかの入力とその計算量との相関関係を分析して，ある程度の情報を推定できるかもしれない。
】</p>

<p>
実施においては、
~appは，同じ時刻~driftを複数回の~naviにわたり観測できる：
~appは、
各~文脈における論理-時刻を記録し，
~client／~server
時刻~同期法の仕組みを利用して、
利用者の時計における変化を推定できる。
類似に，より低い層における仕組み
— ~TCP時刻印など —
は、
複数回の訪問を要することなく，同じ高分解能な情報を~serverに露呈し得る。
そのようなわけで，この~APIにより供される情報は、
有意な, あるいは以前までは可用でなかった，利用者についての~entropyを公開するベキでない。
◎
In practice, the same time drift can be observed by an application across multiple navigations: the application can record the logical time in each context and use a client or server time synchronization mechanism to infer changes in the user's clock. Similarly, lower-layer mechanisms such as TCP timestamps may reveal the same high-resolution information to the server without the need for multiple visits. As such, the information provided by this API should not expose any significant or previously unavailable entropy about the user.
</p>

		</section>
	</section>
	<section id="sec-privacy">
<h2 title="Privacy Considerations">10. ~privacyの考慮点</h2>

<p>
`文書$用の`時刻~起点$enVの現在の定義は、［
要請が当の文書の生成元に到着するに先立って，
非同一-生成元な~redirectにかかった時間
］を公開する。
これは，非同一-生成元な情報を公開するが、［
処理能~計量に大きな非互換化をもたらすことなく，これを軽減する方法
］は，まだ裁定されていない。
◎
The current definition of time origin for a Document exposes the total time of cross-origin redirects prior to the request arriving at the document's origin. This exposes cross-origin information, however it's not yet decided how to mitigate this without causing major breakages to performance metrics.
</p>

<p>
論点は、
`Navigation Timing 課題 #160＠https://github.com/w3c/navigation-timing/issues/160$
にて追跡されている。
◎
To track the discussion, refer to Navigation Timing Issue 160.
</p>

	</section>
	<section id="acknowledgments">
<h2 title="Acknowledgments">謝辞</h2>

<p>
次に挙げる方々による，この作業に対する貢献に感謝する：
</p>

<p lang="en">
Thanks to Arvind Jain, Angelos D. Keromytis, Boris Zbarsky, Jason Weber, Karen Anderson, Nat Duca, Philippe Le Hegaret, Ryosuke Niwa, Simha Sethumadhavan, Todd Reifsteck, Tony Gentilcore, Vasileios P. Kemerlis, Yoav Weiss, and Yossef Oren for their contributions to this work.
</p>

	</section>
</main></div>