Copyright © 2012 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This
specification
defines
a
Javascript
JavaScript
interface
that
provides
the
current
time
in
sub-millisecond
resolution
and
such
that
it
is
not
subject
to
system
clock
skew
or
adjustments.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This
W3C
publishes
a
Candidate
Recommendation
to
indicate
that
the
document
is
believed
to
be
stable
and
to
encourage
implementation
by
the
First
Public
Working
Draft
developer
community.
The
entrance
criteria
for
this
document
to
enter
the
Proposed
Recommendation
stage
is
to
have
a
minimum
of
two
independent
and
Last
Call
interoperable
user
agents
that
implementation
all
the
features
of
this
specification,
which
will
be
determined
by
passing
the
user
agent
tests
defined
in
the
test
suite
developed
by
the
Working
Draft
for
Group.
The
Working
Group
does
not
expect
to
advance
to
Proposed
Recommendation
prior
to
.
A
preliminary
implementation
report
is
available
and
will
be
updated
during
the
High
Resolution
Time
specification.
Candidate
Recommendation
period.
This
is
a
work
in
progress
and
may
change
without
any
notices.
The Working Group intends to gain implementation experience before recommending implementations to remove their vendor prefixes.
Please
send
comments
to
public-web-perf@w3.org
(
archived
)
with
[HighResolutionTime]
at
the
start
of
the
subject
line
by
10
April
2012
.
line.
This document is produced by the Web Performance Working Group. The Web Performance Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain .
Publication
as
a
Working
Draft
Candidate
Recommendation
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This section is non-normative.
The ECMAScript Language Specification 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 instant that is within approximately 285,616 years from 01 January, 1970 UTC. The DOMTimeStamp is defined similarly.
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.
var mark_start = Date.now(); doTask(); // Some task if (window.console) window.console.log('Duration of task: ' + (Date.now() - mark_start));
For certain tasks this definition of time may not be sufficient as it does not allow for sub-millisecond resolution and is subject to system clock skew. For example,
This
specification
does
not
propose
changing
the
behavior
of
Date.now()
as
it
is
genuinely
useful
in
determining
the
current
value
of
the
calendar
time
and
has
a
long
history
of
usage.
The
DOMHighResTimeStamp
type
and
the
now
method
of
the
Performance
interface
resolve
the
issues
summarized
in
this
section
by
providing
a
monotonically
increasing
time
value
in
sub-millisecond
resolution.
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119 . For readability, these words do not appear in all uppercase letters in this specification.
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.
Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on user agents.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [Web IDL]
The
construction
"a
Foo
object",
where
Foo
is
actually
an
interface,
is
sometimes
used
instead
of
the
more
accurate
"an
object
implementing
the
interface
Foo
".
The
term
DOM
is
used
to
refer
to
the
API
set
made
available
to
scripts
in
Web
applications,
and
does
not
necessarily
imply
the
existence
of
an
actual
Document
object
or
of
any
other
Node
objects
as
defined
in
the
DOM
Core
specifications
.
A DOM attribute is said to be getting when its value is being retrieved (such as by author script), and is said to be setting when a new value is assigned to it.
The term "JavaScript" is used to refer to ECMA-262 , rather than the official term ECMAScript, since the term JavaScript is more widely known.
This section is non-normative.
This specification defines an interface that provides the current time in sub-millisecond resolution and such that it is not subject to system clock skew or adjustments.
DOMHighResTimeStamp
Type
The
DOMHighResTimeStamp
type
is
used
to
store
an
absolute
or
relative
a
time
value
measured
from
relative
to
the
navigationStart
attribute
of
the
PerformanceTiming
interface
[NavigationTiming]
,
the
start
of
navigation
of
the
document.
document,
or
a
time
value
that
represents
a
duration
between
two
DOMHighResTimeStamps
.
A
DOMHighResTimeStamp
represents
SHOULD
represent
a
number
of
milliseconds
accurate
to
at
least
a
tenth
thousandth
of
a
millisecond.
If
the
User
Agent
is
unable
to
provide
a
time
value
accurate
to
a
thousandth
of
a
millisecond
due
to
hardware
or
software
constraints,
the
User
Agent
can
represent
a
DOMHighResTimeStamp
as
a
number
of
milliseconds
accurate
to
a
millisecond.
typedef double DOMHighResTimeStamp;
Performance
interface
partial interface Performance { DOMHighResTimeStamp now(); };
now
method
The
now
method
MUST
return
a
DOMHighResTimeStamp
representing
the
number
of
milliseconds
from
the
navigationStart
attribute
of
the
PerformanceTiming
interface
[NavigationTiming]
,
the
start
of
navigation
of
the
document,
to
the
occurrence
of
the
call
to
the
now
method.
As the now method returns the current time, time spent while a document is hidden or not fully active is included for the purpose of this method.
The
time
values
returned
when
calling
the
now
method
MUST
be
monotonically
increasing
and
not
subject
to
system
clock
adjustments
or
system
clock
skew.
The
difference
between
any
two
chronologically
recorded
time
values
returned
from
the
now
method
MUST
never
be
negative.
Statistical
fingerprinting
is
a
privacy
concern
where
a
malicious
web
site
may
determine
whether
a
user
has
visited
a
third-party
web
site
by
measuring
the
timing
of
cache
hits
and
misses
of
resources
in
the
third-party
web
site.
Though
the
now
method
of
the
Performance
interface
returns
time
data
to
a
greater
accuracy
than
before,
it
does
not
make
this
privacy
concern
significantly
worse
than
it
was
already.