quickwit-oss/quickwit · error

Failed to parse date time: {}

Error message

Failed to parse date time: {}

What it means

parse_and_convert takes a string date literal from a range query and parses it with the configured StrptimeParser, converting the result to RFC3339. This error is raised when the date-time string does not match the expected format — the inner reason carries the parser's explanation of where parsing failed.

Source

Thrown at quickwit/quickwit-query/src/elastic_query_dsl/range_query.rs:133

            upper_bound: match (lt, lte) {
                (Some(_lt), Some(_lte)) => {
                    anyhow::bail!("both lt and lte are set")
                }
                (Some(lt), None) => Bound::Excluded(lt),
                (None, Some(lte)) => Bound::Included(lte),
                (None, None) => Bound::Unbounded,
            },
        };
        let ast: QueryAst = range_query_ast.into();
        Ok(ast.boost(boost))
    }
}

fn parse_and_convert(literal: JsonLiteral, parser: &StrptimeParser) -> anyhow::Result<JsonLiteral> {
    if let JsonLiteral::String(date_time_str) = literal {
        let parsed_date_time = parser
            .parse_date_time(&date_time_str)
            .map_err(|reason| anyhow::anyhow!("Failed to parse date time: {}", reason))?;
        let parsed_date_time_rfc3339 = parsed_date_time.format(&Rfc3339)?;
        Ok(JsonLiteral::String(parsed_date_time_rfc3339))
    } else {
        Ok(literal)
    }
}

#[cfg(test)]
mod tests {
    use std::ops::Bound;

    use super::{RangeQuery as ElasticRangeQuery, RangeQueryParams as ElasticRangeQueryParams};
    use crate::JsonLiteral;
    use crate::elastic_query_dsl::ConvertibleToQueryAst;
    use crate::query_ast::{QueryAst, RangeQuery};

    #[test]
    fn test_date_range_query_with_format() {

View on GitHub (pinned to a39730c5cd)

Solutions

1. Format the date literal to match the query's declared format exactly (e.g. "2024-01-02 15:04:05" for "yyyy-MM-dd HH:mm:ss")
2. Use RFC3339 ("2024-01-02T15:04:05Z") and drop the custom format
3. Replace date-math expressions (now-1d) with computed absolute timestamps
4. Include the timezone offset in the string if the format expects one

Example fix

// before
{"range": {"ts": {"gte": "now-1d", "format": "yyyy-MM-dd HH:mm:ss"}}}
// after
{"range": {"ts": {"gte": "2026-09-07 00:00:00", "format": "yyyy-MM-dd HH:mm:ss"}}}

function isValidDate(s, fmt) {
  try { parseWithStrptime(s, fmt); return true; } catch { return false; }
}

match convert_to_query_ast(json, ...) {
    Err(e) if e.to_string().contains("Failed to parse date time") => { /* surface user-facing message with expected format */ }
    Err(e) => return Err(e),
    Ok(ast) => ast,
}

When it happens

Trigger: A range query provides gt/gte/lt/le values as strings that don't conform to the declared format — e.g. "01/02/2024" against format "yyyy-MM-dd", or "now-1d" style expressions with a strict strptime format.

Common situations: Users passing Elasticsearch date math (now-1h/d) or locale-formatted dates to range queries; timezone-naive strings against a format expecting offsets; wrong field ordering in the date string.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• Unsupported minimum should match dsl {}. quickwit currently
• failed to parse range query date format. {err}
• failed to parse --{}-date option parameter `{}`. supported f
• fields and default_field cannot be both set in `query_string
• both gt and gte are set

AI-assisted analysis of quickwit-oss/quickwit@a39730c5cd (2026-09-08). Data as JSON: /api/errors/288b1ebe77392aa8. Report an issue: GitHub.