OpenTelemetry Span Timestamps: No Time‑Zone Context for Local Display

Question

Problem Statement
OpenTelemetry records span start and end times as 64‑bit nanosecond epoch values (e.g., start_time_unix_nano), which are implicitly UTC. The core specification does not attach a time‑zone identifier or civil date string to these timestamps.
Unresolved Decision
When a trace is consumed by a UI or exporter, the same epoch value may be rendered as different local times depending on the viewer’s locale. Because the source time zone is not conveyed, there is no standard way for backends to reconstruct the original local time of the event.
Key Questions

Should OpenTelemetry introduce a standard attribute (e.g., source_time_zone) that propagates the host’s local time zone with each span?
If not, how should backends decide whether to display timestamps in UTC, the viewer’s local time, or the host’s local time?
What best practices can be defined for exporters to preserve or annotate the original time zone context?

Zoha · Answer

Problem Summary
The OpenTelemetry specification records span start and end times as 64-bit UTC nanosecond epoch values (start_time_unix_nano, end_time_unix_nano) without attaching a time-zone identifier or civil date string. When a UI or exporter renders these values, the same epoch may appear as different local times depending on the viewer's locale, creating ambiguous displays.
Key Question Answers

Introducing a standard source_time_zone attribute would require a major spec change and risk breaking backward compatibility with existing instrumentation and exporters.
Backends lacking a conveyed time zone should default to UTC or the viewer's local time, explicitly documenting the chosen policy.
Exporters may optionally emit a non-standard source_time_zone attribute, but consumers should treat it as advisory and fall back to UTC or the configured locale.

Likely Explanation vs Confirmed Facts
Likely: the OTel design prioritized machine-agnostic epoch exchange, assuming downstream systems would apply their own timezone logic. Confirmed: the current spec contains no mandatory time-zone attribute; common SDKs expose only start_time_unix_nano and end_time_unix_nano in standard span data.
Recommended Steps for This Case

Preserve the original epoch value in every export; do not truncate or convert before storage.
If a source_time_zone attribute is present, treat it as advisory and default to UTC or the viewer's locale per your organization's policy.
Document the assumed or inferred time zone in UI metadata so that display choices are transparent.
For exporters: consider emitting source_time_zone as a vendor-extended attribute only when your pipeline absolutely requires host-local display, and clearly note its non-portable nature.

Missing diagnostic detail: which OpenTelemetry SDK language and version are you using? This determines whether the SDK exposes process-timezone environment variables or already emits custom attributes, and whether a targeted source_time_zone addition would be viable or if a UI-level normalization approach is preferable.

OpenTelemetry Span Timestamps: No Time‑Zone Context for Local Display

Problem Statement

Unresolved Decision

Key Questions

1 answer

Problem Summary

Key Question Answers

Likely Explanation vs Confirmed Facts

Recommended Steps for This Case

Your perspective belongs here.

0 question comments