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

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?