influxdata/influxdb · error

timestamp, {}, out of range for precision: {:?}

Error message

timestamp, {}, out of range for precision: {:?}

What it means

Precision::to_nanos converts a unit-less i64 timestamp to nanoseconds by multiplying by the precision multiplier (s=1_000_000_000, ms=1_000_000, us=1_000, ns=1) via checked_mul. With Precision::Auto the unit is guessed from the value's magnitude (thresholds chosen so guess-based conversion essentially never overflows); with an explicitly supplied precision, a raw value too large for the declared unit overflows i64 nanoseconds (the ~1677-09-21..2262-04-11 range) and returns this error.

Source

Thrown at influxdb3_types/src/write.rs:56

    ///
    /// The method properly handles Precision::Auto which is meant to infer the units of
    /// the timestamp, but doesn't apply if the default is being used.
    ///
    /// The returned value has units of nanoseconds in all cases.
    pub fn to_nanos(
        &self,
        timestamp: Option<TimestampNoUnits>,
        default_timestamp: Nanoseconds,
    ) -> Result<Nanoseconds, anyhow::Error> {
        debug_assert!(
            default_timestamp >= 0,
            "in modern era, the default timestamp should be positive"
        );
        match timestamp {
            Some(ts) => {
                let multiplier = self.infer_precision(ts).multiplier();
                ts.checked_mul(multiplier).ok_or_else(|| {
                    anyhow::anyhow!("timestamp, {}, out of range for precision: {:?}", ts, self)
                })
            }
            None => Ok(self.truncate_to_precision(default_timestamp)),
        }
    }

    /// truncate_to_precision rounds the provided nanosecond value towards zero to a multiple
    /// of precision. If it's auto, nanos is returned unchanged.
    fn truncate_to_precision(&self, nanos: i64) -> i64 {
        match self {
            Precision::Auto => nanos,
            precision => {
                let multiplier = precision.multiplier();
                (nanos / multiplier) * multiplier
            }
        }
    }

View on GitHub (pinned to d28e26e048)

Solutions

1. Match the write precision parameter to the actual unit of the integer values (e.g. precision=ns for ns-epoch integers)
2. Send RFC3339/ISO-8601 timestamp strings instead of raw integers when units are uncertain
3. Validate client-side that ts.checked_mul(multiplier) fits in i64 before writing
4. Cleanse sources that put non-time numeric data into the timestamp field

Example fix

# before: ns-epoch integers declared as seconds
client.write('m,t=1 v=2 1755350400000000000', precision='s')  # ns * 1e9 -> overflow

# after
client.write('m,t=1 v=2 1755350400000000000', precision='ns')
# or send RFC3339: m,t=1 v=2 2026-08-16T12:00:00Z

# Python client-side check before writing raw integer timestamps
MULT = {'s': 10**9, 'ms': 10**6, 'us': 10**3, 'ns': 1}
I64_MAX = 2**63 - 1

def ts_ok(ts: int, precision: str) -> bool:
    return -I64_MAX <= ts * MULT[precision] <= I64_MAX

When it happens

Trigger: Writing line protocol with precision=s while the client actually sends nanosecond-epoch integers (1.7e18 * 1e9 overflows); any explicit precision where the values' real unit is finer than declared; or genuine timestamps outside the i64 nanosecond date range for the chosen unit.

Common situations: Client library configured with the wrong precision string; ETL jobs writing raw epoch values with a hard-coded unit; junk numerics (IDs, phone numbers) landing in the timestamp field.

Related errors

• cannot fit duration into u64
• no overflow
• Measurement name cannot contain spaces
• {key_type} key cannot be empty
• {key_type} key '{key}' cannot contain spaces

AI-assisted analysis of influxdata/influxdb@d28e26e048 (2026-08-16). Data as JSON: /api/errors/3e2f22cade0b51f6. Report an issue: GitHub.