-
Notifications
You must be signed in to change notification settings - Fork 897
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
Clarify that 64 bit integer numbers are decimal strings in OTLP/JSON #1637
Clarify that 64 bit integer numbers are decimal strings in OTLP/JSON #1637
Conversation
Resolves open-telemetry/opentelemetry-proto#268 This behavior is already the documented behavior for JSON Protobuf, see https://developers.google.com/protocol-buffers/docs/proto3#json: >JSON value will be a decimal string. Either numbers or strings are accepted.
In collector exporter the number will be sent as When we send data as proto then the whole data is being converted using |
@obecny Neither int32 nor double are good enough for timestamps (which is one of the most common uses cases for 64 bit integers in proto). int32 does not have enough range, double does not have enough precision. I do not know what are the options to deal with 64 bit integer numbers in JS and I understand it is painful but unfortunately this is the current reality of the proto. This PR does not change that at all. This is just a clarification of how 64 bit integer numbers (which we have plenty in OTLP) work in Protobuf JSON encoding. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
The data model says that timestamps are nanosecond values, but examples use milliseconds. Updated to use stringified nanoseconds according to open-telemetry#1637 Fixes: open-telemetry#1049
The data model says that timestamps are nanosecond values, but examples use milliseconds. Updated to use stringified nanoseconds according to open-telemetry#1637 Fixes: open-telemetry#1049
The data model says that timestamps are nanosecond values, but examples use milliseconds. Updated to use stringified nanoseconds according to open-telemetry/opentelemetry-specification#1637 Fixes: open-telemetry/opentelemetry-specification#1049 Co-authored-by: Sergey Kanzhelev <S.Kanzhelev@live.com>
…pen-telemetry#1637) Resolves open-telemetry/opentelemetry-proto#268 This behavior is already the documented behavior for JSON Protobuf, see https://developers.google.com/protocol-buffers/docs/proto3#json: >JSON value will be a decimal string. Either numbers or strings are accepted.
Resolves open-telemetry/opentelemetry-proto#268
This behavior is already the documented behavior for JSON Protobuf,
see https://developers.google.com/protocol-buffers/docs/proto3#json: