Elasticsearch data stream `@timestamp` carries microsecond precision, not OTLP nanoseconds

[yurishkuro]

What happens

The Elasticsearch/OpenSearch v2 write path converts OTLP timestamps to microseconds before anything else sees them, so the @timestamp field that data streams partition on carries microsecond resolution even though it is mapped as date_nanos:

• internal/storage/v2/elasticsearch/tracestore/to_dbmodel.go:159 sets StartTime: model.TimeAsEpochMicroseconds(startTime), and that helper is uint64(t.UnixNano() / 1000) — the last three digits of the OTLP timestamp are discarded here.
• dbmodel.Span.StartTime is declared // microseconds since Unix epoch (internal/storage/v2/elasticsearch/tracestore/core/dbmodel/model.go:52).
• SpanWriter.WriteSpans formats that field for @timestamp (internal/storage/v2/elasticsearch/tracestore/core/writer.go:117), so the string it writes has at most six fractional digits.

This is not new and it is not a regression from #9363, which only changed the encoding from a number to an RFC 3339 string. The truncation predates data streams: it is how the legacy Jaeger span schema has always stored startTime.

Why it is worth recording

Two reasons, one cosmetic and one real.

The RFC is inaccurate. RFC 0004 §3.3 says @timestamp is "derived from the OTLP StartTimestamp at nanosecond precision" and gives "OTLP defines timestamps in nanoseconds; truncating to milliseconds loses precision unnecessarily" as the rationale for date_nanos. The type choice is right — microseconds still need sub-millisecond precision, and a plain date would truncate them — but the stated precision is not what the pipeline delivers.

The behavior may or may not be what we want. Spans emitted by high-resolution instrumentation lose sub-microsecond start times on the way into Elasticsearch, and two spans within the same microsecond sort arbitrarily. Whether that matters is a product question nobody has asked out loud yet, which is why this is an issue rather than a patch.

Options

Criterion	A. Document the real resolution	B. Carry nanoseconds for @timestamp only	C. Make StartTime nanoseconds
OTLP fidelity	🔴 stays microseconds	🟢 full nanoseconds in @timestamp	🟢 full nanoseconds everywhere
Storage schema stability	🟢 unchanged	🟡 one added field	🔴 changes the meaning of an existing field
Query-path impact	🟢 none	🟢 none — @timestamp has no readers	🔴 every reader, the UI, and stored data
Backward compatibility	🟢 none needed	🟢 additive	🔴 needs migration for existing indices
Effort	🟢 one line of prose	🟡 thread the original timestamp through to_dbmodel	🔴 large
User-visible benefit	🔴 none	🟡 finer rollover and sort granularity	🟡 same, plus precise startTime

🟢 good 🟡 partial 🔴 poor

Recommendation

A, and revisit B only if someone reports needing it.

@timestamp exists for rollover and time-based partitioning, where the difference between microsecond and nanosecond granularity has no operational effect: rollover happens on the scale of hours. Every Jaeger read path, the query API, and the UI already work in microseconds, so B would create a field whose precision nothing consumes, and C changes a schema shared with the legacy write path for the same non-benefit. The honest fix is to say microseconds in the RFC and keep date_nanos, which remains the correct type because date cannot hold microseconds at all.

If B ever becomes worthwhile, the narrow version is cheap: to_dbmodel.go already holds the untruncated span.StartTimestamp().AsTime(), so it could set the @timestamp string there instead of letting the writer re-derive it from the microsecond field.

[DsThakurRawat]

Option A is already done, unless I'm reading the tree wrong. 95564508 (#9375) rewrote RFC 0004 §3.3: line 221 now says the value "carries microsecond resolution rather than the nanoseconds OTLP defines" and points here, and the future-work list gained "Preserve OTLP nanosecond precision in @timestamp, if it proves worthwhile". So the documentation half of this issue closed the same day it opened, and what's actually open is B versus C versus leaving it alone.

I measured the loss so the numbers are in the thread. One OTLP span at 2026-08-20T12:00:00.123456789Z through ToDBModel and back out the way core/writer.go:117 formats it:

OTLP  UnixNano : 1787227200123456789
dbmodel StartTime (us): 1787227200123456
round-trip UnixNano   : 1787227200123456000
nanoseconds lost      : 789
@timestamp string     : 2026-08-20T12:00:00.123456Z
OTLP as RFC3339Nano   : 2026-08-20T12:00:00.123456789Z

Worst case is 999ns, and two spans 999ns apart come out with a byte-identical @timestamp. So the sorting concern you raised is real but bounded to a microsecond bucket.

Two things I checked that push toward A or B rather than C:

• Your "no readers" row holds up. grep -rn '@timestamp' --include=*.go internal/ cmd/ finds only the json tag on dbmodel.Span.Timestamp and a comment in indices/rotation.go. The single assignment is core/writer.go:117. Nothing decodes it, and the reader's own time filter goes through buildStartTimeQuery, which ranges over startTimeMillis at reader.go:575, so the query path is already three orders of magnitude coarser than the field being discussed.
• C would fix one field in a document that is microseconds throughout. to_dbmodel.go:161 writes Duration via DurationAsMicroseconds and :289 writes every span event's Timestamp via TimeAsEpochMicroseconds. A span whose start time is nanosecond-exact but whose duration and event times are not hasn't really gained nanosecond fidelity. On top of that both helpers live in jaeger-idl (model/v1/time.go:21 and :12) and dbmodel.Span.StartTime is shared with the v1 schema, so C is a cross-repo change to a field with existing indexed data behind it.

Which leaves B as the only one that buys anything, and it buys it for a field nothing currently reads. My read is that A is the honest resting place until something actually wants to sort inside a microsecond, and that B is worth doing the day a consumer exists rather than in advance. Happy to be wrong if you've got a use case in mind that I can't see from the code.