Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timestamp: Redefine timestamp in Data delivery #274

Merged
merged 5 commits into from
Jun 7, 2024

Conversation

arskama
Copy link
Contributor

@arskama arskama commented May 30, 2024

Fixes #257


Preview | Diff

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
@arskama arskama requested a review from rakuco June 7, 2024 14:09
Signed-off-by: Arnaud Mandy <arnaud.mandy@intel.com>
index.html Outdated Show resolved Hide resolved
@arskama arskama requested a review from rakuco June 7, 2024 15:35
index.html Outdated Show resolved Hide resolved
Copy link
Member

@rakuco rakuco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@rakuco rakuco merged commit 1b8a56c into w3c:main Jun 7, 2024
2 checks passed
rakuco added a commit that referenced this pull request Jun 12, 2024
Follow-up to #274, related to #257.

The call to the "passes rate test" algorithm should use `timeValue` rather
than `timestamp`: the former is what is stored in `PressureRecord.[[Time]]`,
so it makes sense to compare values that have been similarly coarsened and
converted to a relative time.
rakuco added a commit that referenced this pull request Jun 12, 2024
Follow-up to #274, related to #257.

The wording used in #274, which mentions platform-specific timestamps, made
more sense in the context of the Generic Sensor API spec, as multiple
platform-specific sensor APIs provide samples with timestamps in a
platform-specific format that needs to be converted.

Of the OS-provided telemetry APIs, however, only Windows optionally provides
samples with a timestamp. As such, it makes more sense to define a timestamp
using the monotonic clock's unsafe current time instead. Aditionally, the
accompanying note was rewritten to indicate that the same value should be
used for all globals, otherwise the same sample would end up with different
"raw" timestamps in different frames/workers.
rakuco added a commit that referenced this pull request Jun 13, 2024
…eck (#279)

Follow-up to #274, related to #257.

The call to the "passes rate test" algorithm should use `timeValue` rather
than `timestamp`: the former is what is stored in `PressureRecord.[[Time]]`,
so it makes sense to compare values that have been similarly coarsened and
converted to a relative time.
rakuco added a commit that referenced this pull request Jun 13, 2024
Follow-up to #274, related to #257.

The wording used in #274, which mentions platform-specific timestamps, made
more sense in the context of the Generic Sensor API spec, as multiple
platform-specific sensor APIs provide samples with timestamps in a
platform-specific format that needs to be converted.

Of the OS-provided telemetry APIs, however, only Windows optionally provides
samples with a timestamp. As such, it makes more sense to define a timestamp
using the monotonic clock's unsafe current time instead. Aditionally, the
accompanying note was rewritten to indicate that the same value should be
used for all globals, otherwise the same sample would end up with different
"raw" timestamps in different frames/workers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Is PressureRecord.time a timestamp or a time that is relative to timeOrigin?
2 participants