influxdata/influxdb · error · Error

Cannot parse the given human time

Error message

Cannot parse the given human time: {0}

What it means

This error is the `ParsingHumanTime(#[source] humantime::DurationError)` variant of the HTTP server's `Error` enum in influxdb3_server/src/http.rs, rendered as "Cannot parse the given human time: {0}". It is thrown when a human-readable duration supplied via HTTP query parameters (e.g. relative time ranges like `now()-30m` window or lookback parameters) cannot be parsed by the `humantime` crate. The original humantime::DurationError is attached as the source.

Solutions

1. Use humantime-accepted syntax: combinations of seconds/minutes/hours/days, e.g. `30s`, `15m`, `2h`, `1d 4h`
2. Read the `source` (humantime::DurationError) message to see the exact offending character/position
3. Check the docs for the specific parameter — if it expects a timestamp not a duration, use RFC3339 instead
4. Trim whitespace/quotes from the parameter value

Example fix

// before
curl -X POST 'http://localhost:8181/api/v3/query_sql' -d '{"db": "weather", "q": "SELECT * FROM temps", "start": "last 30 mins"}'
// after
curl -X POST 'http://localhost:8181/api/v3/query_sql' -d '{"db": "weather", "q": "SELECT * FROM temps", "start": "30m"}'

// validate human duration before sending
const HUMAN_RE = /^(\s*\d+\s*(ns|us|ms|sec|secs|second|seconds|minutes|min|mins|m|hours|hour|hr|hrs|h|days|day|d|weeks|week|w)\s*)+$/i;
if (!HUMAN_RE.test(durationStr)) {
  throw new Error(`invalid human duration: ${durationStr} (use e.g. 30m, 2h 15m)`);
}

try {
  await query(db, sql, { start: durationStr });
} catch (e) {
  if (e.message.startsWith('Cannot parse the given human time')) {
    throw new Error(`Bad duration '${durationStr}': use humantime syntax like 30m, 1h 30m`, { cause: e });
  }
  throw e;
}

When it happens

Trigger: Passing a malformed human-duration string in an HTTP API parameter that the server parses with `humantime::parse_duration` (e.g. relative time/window/retention-style parameters in query requests).

Common situations: Writing `30mins` or `1.5h` or `30 m` instead of humantime-accepted forms like `30m`, `1h 30m`; pasting a timestamp where a duration is expected (or vice versa); locale-formatted durations; trailing whitespace or units humantime does not accept (e.g. `wk`, `mo`).

Understand the failure class

Background: "invalid duration" / "failed to parse duration": why your timeout, interval, or TTL string is rejected and which formats each library accepts — this error's family across 32 libraries.

Related errors

• Cannot parse the timestamp
• Timestamp is out of range
• {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/4865554154f07650. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_server/src/http.rs:379

    #[error("Processing engine error: {0}")]
    ProcessingEngine(#[from] influxdb3_processing_engine::manager::ProcessingEngineError),

    #[error(transparent)]
    Influxdb3TypesHttp(#[from] influxdb3_types::http::Error),

    #[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),
}

View on GitHub (pinned to 06200ef96b)