influxdata/influxdb · error · Error

Timestamp is out of range

Error message

Timestamp is out of range

What it means

This error is the `TimestampOutOfRange` unit variant of the HTTP server's `Error` enum in influxdb3_server/src/http.rs, rendered as "Timestamp is out of range". It is thrown when a parsed timestamp is valid RFC3339 but falls outside the range the server accepts (e.g. outside the representable nanosecond range of i64 for the query planner, or before/after bounds the query window allows).

Solutions

1. Constrain start/stop timestamps to realistic dates that fit nanosecond i64 (~1677-09-21 to 2262-04-11, the chrono nanosecond range)
2. Convert epochs with the correct unit (seconds vs ms vs ns) before sending
3. Clamp 'all time' queries to supported bounds or omit the time-range parameters entirely
4. Check the API docs for the exact accepted timestamp range for the parameter

Example fix

// before
{"start_timestamp": "0001-01-01T00:00:00Z", "stop_timestamp": "9999-12-31T23:59:59Z"}
// after
{"start_timestamp": "1970-01-01T00:00:00Z", "stop_timestamp": "2262-04-11T23:47:16Z"}

// clamp timestamps to the representable chrono nanosecond range before sending
const MIN = Date.parse('1677-09-21T00:12:44Z');
const MAX = Date.parse('2262-04-11T23:47:16Z');
function clampTimestamp(iso) {
  const t = Date.parse(iso);
  if (t < MIN || t > MAX) throw new Error(`timestamp ${iso} outside supported range`);
  return new Date(Math.min(Math.max(t, MIN), MAX)).toISOString();
}

function inSupportedRange(iso) {
  const t = Date.parse(iso);
  return !isNaN(t) && t >= Date.parse('1677-09-21T00:12:44Z') && t <= Date.parse('2262-04-11T23:47:16Z');
}

try {
  await query(db, sql, { start_timestamp: start, stop_timestamp: stop });
} catch (e) {
  if (e.message === 'Timestamp is out of range') {
    return query(db, sql, { start_timestamp: clampTimestamp(start), stop_timestamp: clampTimestamp(stop) });
  }
  throw e;
}

When it happens

Trigger: Requesting a query time range with a start/stop timestamp far outside supported bounds — e.g. year 0001, year 9999, or epochs that overflow nanosecond i64 conversion — via the HTTP query API.

Common situations: Using `0001-01-01T00:00:00Z` / `9999-12-31...` as sentinel 'beginning of time' bounds; converting millisecond or second epochs incorrectly into nanoseconds and overflowing; time-range variables populated with extreme default values.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• Cannot parse the timestamp
• Cannot parse the given human time
• {error_code}
• failed to build an http client
• failed to parse JSON response

AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/8a73f91a82ce50f5. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_server/src/http.rs:385

    #[error("Authorization error: {0}")]
    ResourceAuthorization(#[from] ResourceAuthorizationError),

    #[error("Authentication error: {0}")]
    Authentication(#[from] AuthenticatorError),

    #[error("The following Database does not exist: {0}")]
    MissingDb(String),

    #[error("The following Database Table does not exist: {0}")]
    MissingTable(String),

    #[error("Cannot parse the given human time: {0}")]
    ParsingHumanTime(#[source] humantime::DurationError),

    #[error("Cannot parse the timestamp: {0}")]
    ParsingTimestamp(#[from] chrono::ParseError),

    #[error("Timestamp is out of range")]
    TimestampOutOfRange,

    #[error("Current node mode does not use the processing engine")]
    NoProcessingEngine,

    #[error("invalid request: {0}")]
    InvalidRequest(String),

    #[error(transparent)]
    LegacyWriteParse(#[from] WriteParseError),
}

#[derive(Debug, Error)]
pub(crate) enum AuthenticationError {
    #[error("the request was not authenticated")]
    Unauthenticated,
    #[error(
        "Authorization header was malformed, the request was not in the form of 'Authorization: <auth-scheme> <token>', supported auth-schemes are Bearer, Token and Basic"

View on GitHub (pinned to 06200ef96b)