Validation error: all time values must include a timezone offset when mixing UTC and zone‑naive timestamps

Question

Goal: Ensure that a Datadog query can combine timestamps expressed as epoch milliseconds (without an explicit zone) and ISO‑8601 strings that include a UTC offset without triggering a validation failure.
Constraints: Datadog’s query editor rejects any request where some timestamps lack a timezone offset, returning the error “all time values must include a timezone offset”. The platform stores all timestamps in UTC, but the conversion logic for epoch‑millisecond values that arrive without a zone is not fully documented, leading to uncertainty about whether such values are interpreted as UTC or as the organization’s default timezone during aggregation.
Uncertainty: It is unclear how Datadog should treat ambiguous zone inputs when aggregating data for visualizations, monitors, or scheduled reports, and whether a default organization timezone is applied to epoch values in those contexts.
Specific questions:

What is the expected interpretation of epoch‑millisecond timestamps that omit a zone when used alongside ISO‑8601 timestamps with offsets?
Does Datadog apply the organization’s default timezone to those epoch values during query execution, or does it treat them as UTC?
How can users structure mixed‑zone queries to avoid the validation error while preserving the intended time alignment?

Siddharth · Answer

Answer
Epoch‑millisecond timestamps that lack an explicit zone are treated as UTC milliseconds since the Unix epoch. Datadog does **not** apply the organization’s default timezone to those values; they remain UTC regardless of org settings. The validation error occurs because the query editor requires every time value to carry an offset.
Confirmed facts

Epoch‑ms values without a zone → interpreted as UTC.
Org default timezone is **not** applied to epoch‑ms values.
Adding an explicit offset (e.g., "Z" for UTC or ±hh:mm) satisfies the validation rule and preserves the original instant.
The `date()` function in Datadog queries automatically converts an epoch‑ms number to an ISO‑8601 string with a UTC offset.

Steps to avoid the validation error

Convert each epoch‑millisecond value to an ISO‑8601 string that ends with "Z" (UTC) or includes the desired offset.
  # Instead of: from 1700000000000 to 1700086400000
# Use:
from "1700000000000Z" to "1700086400000Z"

Alternatively, wrap the epoch values in the `date()` function, which implicitly adds the UTC offset.
  from date(1700000000000) to date(1700086400000)

If you already have ISO‑8601 strings with offsets (e.g., "2023-11-15T12:00:00+02:00"), leave them unchanged; just ensure the epoch values are also offset‑aware as shown above.
Run the query in the Datadog notebook or monitor editor; the validation error should disappear and the time alignment will remain correct because all values now represent the same UTC instants.

When to seek additional detail
If you are using the Datadog API directly rather than the UI query editor, confirm whether the same offset requirement applies by checking the API documentation for your specific Datadog version, as enforcement can differ between UI and API endpoints.

Validation error: all time values must include a timezone offset when mixing UTC and zone‑naive timestamps

1 answer

Answer

Confirmed facts

Steps to avoid the validation error

When to seek additional detail

Your perspective belongs here.

0 question comments