prototype for cumulative per-timeseries start timestamp#7719
Closed
dashpole wants to merge 1 commit intoopen-telemetry:mainfrom
Closed
prototype for cumulative per-timeseries start timestamp#7719dashpole wants to merge 1 commit intoopen-telemetry:mainfrom
dashpole wants to merge 1 commit intoopen-telemetry:mainfrom
Conversation
github-merge-queue bot
pushed a commit
to open-telemetry/opentelemetry-specification
that referenced
this pull request
Feb 24, 2026
Fixes #4184 Prerequisite for #2232. ### Changes This adds requirements around start time handling for metrics SDKs: * Consistently describe the start timestamp as "The `start` timestamp best represents the first possible moment a measurement for this timeseries could have been recorded." * Start timestamp MUST be after intervals in which the timeseries was not reported. * Cumulative synchronous instruments SHOULD use the first measurement time as the start timestamp This also restates "the start timestamp MUST equal the previous interval's timestamp" from the data model specification to ensure it isn't read as requiring changes for Delta metrics. The effect of this change is that all cumulative metrics SHOULD use at least the previous export interval for "new" timeseries. That should be very straightforward, as it is what is done for delta metrics today. I would love for this to be a MUST, but i'm concerned it could be considered breaking. Additionally, SDKs SHOULD use the current timestamp for "new" timeseries. This could have a performance cost, so it isn't a MUST. ### Omissions While it is possible for delta metrics to track the attribute sets exported in the previous interval, it is expensive to do so because it requires tracking the attribute sets that were present in the previous collection interva. This would enable SDKs to differentiate between an "unbroken" series, and a "new" one to provide a more accurate start time when observing "new" series. I doubt this is something delta backends would care about enough to be worth the cost. cc @ArthurSens @atoulme @jmacd ### Prototypes * Go: open-telemetry/opentelemetry-go#7719
dashpole
added a commit
that referenced
this pull request
Mar 18, 2026
Add a feature to use per-series start times to match the spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#start-timestamps This is a prerequisite to [finishing / closing](open-telemetry/opentelemetry-specification#4702). Previous prototype: #7719 --------- Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com> Co-authored-by: Robert Pająk <pellared@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prototype for open-telemetry/opentelemetry-specification#4807
Tests would also need to be updated because the "fake time" relies on how often
now()is invoked, but I didn't do that here.