►
From YouTube: WebPerfWG call 2023 06 22 - timeOrigin
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Yes,
okay,
okay,
so
I'd
like
to
present
some
findings
having
dug
into
the
time
origin
attribute
a
little
bit
over
the
last
few
weeks
we
for
our
run
product
for
for
impulse
and
Boomerang
utilize,
of
course,
a
lot
of
the
performance
timing
apis
and
a
lot
of
the
time
we
want
to
or
need
to
convert
things
like
time,
origin
or
Dom,
high-res,
timestamps
into
a
date
to
time
a
Time
an
actual
time
stamp.
A
You
know
wall
timestamp,
and
so
in
reviewing
our
JavaScript
code
for
boomerang.js
I
found
in
many
places
we
were
using
time,
origin,
the
attribute
performance,
stat
time,
origin
and
in
many
other
places
we
were
using.
The
alternate
attribute,
which
are
the
earlier
attribute,
which
is
performance.timing.navigationstart
and
I,
found
a
lot
of
challenges.
A
In
doing
this,
I
was
trying
to
be
consistent,
Even
in
our
internal
code
to
always
use
time,
origin,
which
is
a
more
modern
interface,
but
have
not
been
able
to
do
so
and
I
don't
believe
we
actually
can
based
on
some
of
these
challenges.
So
I
wanted
to
bring
it
to
the
group
and
just
confirm
a
couple
things
maybe
ask
for
some
clarifications.
In
the
spec
and
then
point
out
some
browser
issues
that
I
was
seeing
as
well,
because
there
may
be
some
people
here.
That
could
help
me
with
that
of
course.
A
So
what
is
the
meaning
of
time?
Is
the
subtitle
of
this
presentation.
So
in
the
beginning,
the
very
very
first
thing
that
this
working
group
shipped
was
navigation
timing
and
in
that
we
had
performance.timing.navigationstart,
and
that
is
a
Unix
Epoch
based
timestamp,
a
very
large
number,
and
we
would
often
use
that
as
kind
of
like
the
basis
for
again
when
the
user
clicked
or
you
know,
opened
a
browser
to
navigate
Etc.
A
All
of
the
timestamps
under
performance.timing
are
in
Unix
Epoch
based
timestamps.
So
they
all
look
this
big
and
some
of
you
may
or
may
not
know
that
we
have
actually
since
deprecated
the
timing
interface
and
the
suggestion
is
to
use
the
performance
Observer
and
the
getting
the
entry
of
navigation
instead.
A
But
that's
it's
kind
of
separate
topic.
So,
in
the
beginning,
we
we
have
this
interface,
you
you
look
at
it
to
see
the
actual
time
stamp
of
when
the
navigation
started,
and
it's
now
listed
as
deprecated,
though
everybody
still
ships.
This
interface.
A
And
with
that
navigation
start
epic
timestamp,
we
also
had
they
had
some
friends.
It
had
another
interface
that
we
know
of
called
the
dime
high
res
timestamp.
What
a
mouthful
you
would
access
that
by
using
performance.now,
for
example-
and
that
gives
you
a
Dom
high
res
timestamp
back.
This
is
in
milliseconds
and
what
you
can
do
is
then
you
could
convert
this
performance
that
now
timestamp
that
you
got
and
if
you
added
it
to
your
time,
origin
or
to
navigation
start
you
get
kind
of
the
equivalent.
A
What
is
the
you
know?
Unix
epic,
in
milliseconds
timestamp
up
now
you
can
also
get
these
Diamond
hammers
timestamps
by
any
of
the
performance
entries.
Of
course,
start
time
and
all
of
the
other
attributes
with
performance
entries
are
in
downtown
high
risk
timestamp.
A
So
with
their
powers
combined,
you
know
you
can
take
a
dab,
high-res
timestamp.
You
can
add
it
to
something
like
timing,
that
navigation
start
or
performance.time
origin.
Theoretically,
and
if
you
add
the
two
of
them
together,
you
get
the
you
know,
essentially
the
current
epic
right,
so
the
performance
set
now
is
always
increasing.
The
navigation
start
stays
the
same.
But
if
you
add
the
two
two
of
them
together,
you
get
now
ish.
A
A
So
that
sounds
all
straightforward
and
then
we
said,
let
there
be
time
origin
so
time.
Origin
is
a
an
evolution.
I
think
that
happened
in
navigation
timing
too.
We
it's
just
an
attribute
on
performance
instead
of
it
being
performance
at
timing,
that
navigation
start
it's
just
the
performance
set
time
origin.
A
It
can
be
in
microsecond
resolution,
that's
optional,
and
you
know
it's
meant
to
be
the
evolution
of
what
navigation
start
was
once
we
deprecated
that
timing
interface,
we
needed
to
still
have
these
start
time
stamps,
so
we
moved
it
to
a
Time
origin
attribute
made
a
a
thing
that
may
have
higher
resolution,
and
then
we
deprecated
the
old
interface
at
the
same
time.
A
A
So
what
many
of
us
do
in
ROM
is,
you
know
we
looked.
We
gracefully
fall
back
to
whatever
interfaces
are
available
for
us.
I
was
asking
some
questions
in
the
web
for
slack
a
little
bit
while
ago
about
who's
using
time.
Origin
navigation
start
et
cetera
and
request
metrics.
That
said,
this
is
essentially
the
code
that
they
use
and
this
kind
of
mirror
some
code
that
we
have
in
Boomerang.
But
if
you
want
to
like
get
your
time
origin
for
your
analytics
script,
you
would
first
look
at
performance
at
time,
origin.
A
If
not,
you
look
at
the
timing
that
navigation
star
and,
if
not,
you
know,
just
fall
back
to
date,
deck
at
a
time
which
does
not
have
the
same
benefits
of
the
other
two
interfaces,
and
then
you
can
do
a
new
date
plus
you
know
getting
those
two,
your
current
timestamp
and
then
your
time,
origin,
I,
guess
that
should
be
my
time:
origin
to
get
now.
Theoretically,
so
I
started
going
down
the
path
of
changing
our
library
to
be
more
consistent
and
always
use
time
origin.
A
If
available
falling
back
to
navstar
falling
back
to
daytime
and
started
getting
a
lot
of
problems
with
our
testing,
Suite
and
I
started
digging
into
it
and
I'm
just
seeing
a
lot
of
funny
things,
so
one
confusing
part
to
me
is
what,
if
the
time,
origin
and
navigation
start
are
different,
what
does
that
mean
see
like
in
you
know,
internally
I
would
have
thought
that
time
margin.
A
The
navigation
start
should
have
always
been
the
same
thing,
because
we
basically
moved
it
from
performance
at
timing
to
time,
origin,
and
then
you
know
it
was
supposed
to
be
this.
The
same
time
step
when
the
when
the
user
clicked
in
practice,
it
can
be
very
different,
for
example,
in
the
most
recent
Firefox
and
safaris
they
may
be
plus
or
minus
one
millisecond,
and
you
know,
maybe
that's
just
due
to
rounding
I,
don't
know,
but
I,
don't
know
why.
A
If
it
was
due
to
rounding
and
and
either
like
both
Firefox
and
Safari,
don't
show
a
microsecond
resolution
why
they
wouldn't
just
always
be
the
exact
same
like?
Are
we
rounding
one
differently
than
the
other
or
like
they
shouldn't
be
the
same?
In
my
opinion,
my
professional
fitting
yeah
and
you
know
Safari
shows
the
same
thing
in
Chrome.
We
also
do
see
a
difference.
However,
we
see
the
difference
being
the
difference
in
navigation
start
not
having
microsecond
resolution
and
time
origin.
A
We
do
see
it
and
so
the
two
of
those
like
you,
it's
a
it's
more
obvious
in
that
way,
right,
like
the
difference
between
time,
origin
and
navigation
start
is
because
of
just
the
the
available
resolution
of
that
interface
between
the
two
of
them.
So
that
makes
a
little
bit
more
sense
to
me.
So
if
anything,
you
know,
in
my
opinion,
these
these
numbers
should
always
be
the
same
if
they
have
the
same
resolution
and
and
as
you
know,
as
Chrome's-
probably
okay
here,
but
these
two
are
slightly
more
confusing.
A
Of
course,
that's
pretty
minor,
but
can
they
be
different
is
is
one
of
my
big
questions.
There
is
some
text
in
so
and
there's
it's
not
just
my
questions.
There's
many
other
people
have
asked
this
question
in
various
GitHub
issues
and
I.
Think
Chrome
Dev
mailing
lists
a
link
to
some
of
these
in
these
slides
and
pretty
much
a
lot
of
the
questions
in
these
issues
are
related
to
like.
Why
are
they
different
like?
Should
they
be
different?
Can
they
be
different?
Is
it
a
bug?
A
A
A
You
know,
previous
chairs
and
and
other
people
that
responded
to
issues
have
all
confirmed
that
that
was
the
intent.
I
think
that
they
should
match.
A
I
was
looking
through
the
spec
and
I
was
trying
to
trying
to
figure
out
based
on
the
wording
of
time
origin.
Could
they
ever
be
different,
and
maybe
one
case
that
could
allow
for
the
time
origin
to
be
different
than
navigation
start?
A
Is
when
the
browsers
like
launched
from
a
blank
slate,
possibly-
and
maybe
in
that
case,
because
it
says
the
time
margin
when
the
browser
context
is
first
created
and
then
maybe,
if,
like
the
navigation,
doesn't
start
for
a
moment
later
or
something
I,
don't
know,
I
I,
don't
know
if
that's
like
a
spec
allowed
for
them
to
be
different
to
me,
it's
confusing
that
they
could
ever
be
different
at
all,
but
maybe
it's
allowed
in
the
spec
and
then
so
just
some
general
confusion
about
that.
A
But
we
I've
seen
browser
bugs
as
well
in
all
three
browsers
around
this
here's
a
chromium,
an
example
of
a
chromium
bug.
There
were
some
issues
with
if
I
remember
correctly,
some
drift
that
was
happening
with
time
origin
and
they
would
kind
of
get
away
from
the
desired
value.
I
think
this
one
is
fixed
or
currently
shipping
or
going
to
be
shipped
soon,
but
it
was.
It
was
resulting
in
the
the
time
origin
attribute
being
different
than
what
you
would
expect
from
navigation
start.
A
Firefox
has
has
a
similar
issue
where
I
think
it
in
some
cases,
and
possibly
in
an
older
version
of
Firefox
time,
origin
was
shared
between
multiple
between
the
different
tabs
in
a
process
or
something
and
and
I
I
personally
experienced
examples
where
there
was
10,
milliseconds,
400,
milliseconds,
even
20
hour,
difference
between
time,
origin
and
navigation
star
that
I
didn't
know
what
to
do
to
make
that
and
I
think
in
that
case,
like
maybe
I,
started
the
browser
you
know
yesterday
closed
my
laptop
opened
back
up
and
checked
and
like
a
new
navigation,
had
those
those
the
difference
between
the
two
of
those
be
completely
and
say
no
and
then
Safari
has
an
issue
with
time
origin.
A
Well,
it
actually
changes
over
time.
So,
like
the
actual,
if
you
query
performance
that
time
origin
on
the
exact
same
page
just
over,
you
know
a
few
minutes
a
few
hours
it
drifts
like
these
are.
This
is
one
minute
apart
and
time
origin
you
can
see.
A
Actually,
this
time
margin
here
changed
from
26
to
28
to
35
and
then,
like
a
few
days
later,
it
was
you
know
many
hours
for
many
days
off
of
what
it
had
originally
started
as-
and
these
are
probably
just
all
browser
bugs
no
file
browser
bugs
if
I
can't
find
them
I
couldn't
find
anything
covering
this,
but
it
you
know,
and
it
this
is
confusing,
but
like
this,
this
attribute
should
never
change
time.
Origin
should
never
change.
A
So
you
know
what,
if
what
if
we
want
to,
if
we're
trying
to
switch
to
using
time,
origin
and
if
time
origin
can
be
different
than
navigation
start
and
again,
I,
don't
know.
A
We
force
it
to
be
zero
in
the
spec,
but
if
the
time
origin
and
the
actual
navigation
were
different
by
10
milliseconds,
the
navigation
entry
start
time
should
not
be
zero,
it
should
be
10
milliseconds
and
our
spec
forces
it
to
be
zero.
A
So
I
guess
there's
just
some
confusion
around
what
what
is
allowed,
what
should
be
allowed
and
if
the
time
origin
and
navigation
start
could
be
different
time
stamps.
That
I
think
we
should
allow
for
getting
the
navigation
entries
start
time
to
also
be
different,
as
well,
instead
of
being
forced
to
zero.
A
So
my
summary
of
all
these
crazy
little
edge
cases
that
I'm
finding
is
I
have
a
question
which
is
should
time,
origin
and
timing.
That
navigation
start
be
the
same
again.
This
is
a
deprecated
interface.
A
I
think
it
makes
more
sense
for
them
to
be
the
same,
but
maybe
there's
a
good
reason
for
them
to
be
able
to
to
drift
on
navigation.
I,
don't
know,
there's
definitely
some
browser
books
here,
some
are
fixed.
Some
are
in
progress
being
fixed.
Some
I
need
to
file
a
bug
for
so
I'll
file,
a
bug
for
that
Safari
issue,
but
the
end
result
I
can't
I,
don't
think
we
can
reliably
use
time.
A
Origin
in
Rome
today
as
a
result
between
all
the
different
browsers
behaving
slightly
differently,
and
what
does
it
mean
if
they
differ
and
just
some
of
the
confusion
there
like
I'm,
not
confident
in
using
time
origin
at
the
moment
and
I
think
I'm
just
going
to
keep
us
using
navigation
start
for
now,
which
is
is
not
not
the
goal
of
this
working
group,
so
that
is
my
presentation
and
I'd
be
happy
to
have
discussions
if
anybody
wants
to
about
it.