Check: cases/otlp-logs/timestamp-nanosecond-precision.yaml
What each implementation does
| Backend |
Version |
Observed |
| Parseable |
v2.9.4 |
"…123456789" (string, nanoseconds) → "2026-09-08T09:31:55.123" (string, milliseconds) |
| OpenObserve |
v0.92.2 |
"…123456789" (string, nanoseconds) → 1788859915123456 (number, microseconds) |
| Quickwit |
0.8.2 |
"…123456789" (string, nanoseconds) → 1788859957123456000 (number, nanoseconds holding whole microseconds) |
| VictoriaLogs |
v1.52.0 |
"…123456789" (string, nanoseconds) → "2026-09-08T14:36:09.123456789Z" (string, nanoseconds — kept intact) |
| Loki |
3.1.1 |
"…123456789" (string, nanoseconds) → "1788878689123456789" (string, nanoseconds — kept intact) |
Full reproductions with the exact request are in the case's own notes:.
What the specification says, and where it stops
opentelemetry-proto logs/v1, LogRecord.time_unix_nano:
time_unix_nano is the time when the event occurred, expressed as UNIX
Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970.
The specification defines what the field means and the precision it is sent
at. It does not say what a receiving store must preserve. Two of five stores
here keep the value intact, proving the precision is keepable — that is not
the same as a rule saying it must be kept.
The question put upstream
Not yet filed. Per this project's own policy on posting to repositories it
does not maintain, filing this with the OpenTelemetry specification's owners
needs explicit approval before it goes out — noted here rather than guessed
at, per ADJUDICATION.md: "An issue with no upstream question linked stays
open with nothing to promote."
The question, as it would be put: does the specification intend
time_unix_nano to be an opaque instant a conformant receiver may store at
reduced precision, or does "the time the event occurred" imply the sender's
own precision is part of what is being recorded and ought to survive a round
trip where the backend has the means to keep it (as two of the five
implementations already do)?
Their answer
Pending. This issue stays open until the question above is actually put to
the specification's owners and they answer it.
Check:
cases/otlp-logs/timestamp-nanosecond-precision.yamlWhat each implementation does
"…123456789"(string, nanoseconds) →"2026-09-08T09:31:55.123"(string, milliseconds)"…123456789"(string, nanoseconds) →1788859915123456(number, microseconds)"…123456789"(string, nanoseconds) →1788859957123456000(number, nanoseconds holding whole microseconds)"…123456789"(string, nanoseconds) →"2026-09-08T14:36:09.123456789Z"(string, nanoseconds — kept intact)"…123456789"(string, nanoseconds) →"1788878689123456789"(string, nanoseconds — kept intact)Full reproductions with the exact request are in the case's own
notes:.What the specification says, and where it stops
opentelemetry-proto
logs/v1,LogRecord.time_unix_nano:The specification defines what the field means and the precision it is sent
at. It does not say what a receiving store must preserve. Two of five stores
here keep the value intact, proving the precision is keepable — that is not
the same as a rule saying it must be kept.
The question put upstream
Not yet filed. Per this project's own policy on posting to repositories it
does not maintain, filing this with the OpenTelemetry specification's owners
needs explicit approval before it goes out — noted here rather than guessed
at, per
ADJUDICATION.md: "An issue with no upstream question linked staysopen with nothing to promote."
The question, as it would be put: does the specification intend
time_unix_nanoto be an opaque instant a conformant receiver may store atreduced precision, or does "the time the event occurred" imply the sender's
own precision is part of what is being recorded and ought to survive a round
trip where the backend has the means to keep it (as two of the five
implementations already do)?
Their answer
Pending. This issue stays open until the question above is actually put to
the specification's owners and they answer it.