You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 23, 2023. It is now read-only.
Timestamps in the spec default to the current walltime, which is not monotonic. As a consequence it cannot be guaranteed that start timestamp <= finish timestamp holds.
Problem
The specification currently says about the optional timestamp parameter for log structured data:
An explicit timestamp. If specified, it must fall between the local start and finish time for the span.
This constraint is rather difficult to guarantee. For one, the finish time isn't known when this method is called. Additionally there is the problem of walltime not being monotonic. This means the timezone (+ DST info) needs to be taken into consideration to verify this.
In practice it seems that implementation simply ignore this constraint.
Proposal
I would suggest to bring the spec into alignment with existing implementations. The least invasive way to do so I can see would be to replace the "must" with "should", so that we arrive at:
An explicit timestamp. If specified, it should fall between the local start and finish time for the span.
Questions to address
n/a
The text was updated successfully, but these errors were encountered:
Background
Timestamps in the spec default to the current walltime, which is not monotonic. As a consequence it cannot be guaranteed that start timestamp <= finish timestamp holds.
Problem
The specification currently says about the optional timestamp parameter for log structured data:
https://github.com/opentracing/specification/blob/7d12968e7ffdbbd4032fc1d5346004e840e244ca/specification.md#log-structured-data
Emphasis mine.
This constraint is rather difficult to guarantee. For one, the finish time isn't known when this method is called. Additionally there is the problem of walltime not being monotonic. This means the timezone (+ DST info) needs to be taken into consideration to verify this.
In practice it seems that implementation simply ignore this constraint.
Proposal
I would suggest to bring the spec into alignment with existing implementations. The least invasive way to do so I can see would be to replace the "must" with "should", so that we arrive at:
Questions to address
n/a
The text was updated successfully, but these errors were encountered: