elastic/elasticsearch · error · IllegalArgumentException

unable to parse date [{}]

Error message

unable to parse date [{}]

What it means

Thrown by DateIndexNameProcessor after it has tried every configured date_formats parser against the input value and none succeeded. The exception chains all suppressed parse errors via ExceptionsHelper.useOrSuppress. Unlike DateProcessor, this processor uses the index name rounding/template machinery; the parse failure happens before any of that, on the raw date string.

Source

Thrown at modules/ingest-common/src/main/java/org/elasticsearch/ingest/common/DateIndexNameProcessor.java:85

        String date = null;
        if (obj != null) {
            // Not use Objects.toString(...) here, because null gets changed to "null" which may confuse some date parsers
            date = obj.toString();
        }

        ZonedDateTime dateTime = null;
        Exception lastException = null;
        for (Function<String, ZonedDateTime> dateParser : dateFormats) {
            try {
                dateTime = dateParser.apply(date);
            } catch (Exception e) {
                // try the next parser and keep track of the exceptions
                lastException = ExceptionsHelper.useOrSuppress(lastException, e);
            }
        }

        if (dateTime == null) {
            throw new IllegalArgumentException("unable to parse date [" + date + "]", lastException);
        }
        String indexNamePrefix = ingestDocument.renderTemplate(indexNamePrefixTemplate);
        String indexNameFormat = ingestDocument.renderTemplate(indexNameFormatTemplate);
        String dateRounding = ingestDocument.renderTemplate(dateRoundingTemplate);

        DateFormatter formatter = DateFormatter.forPattern(indexNameFormat);
        // use UTC instead of Z is string representation of UTC, so behaviour is the same between 6.x and 7
        String zone = timezone.equals(ZoneOffset.UTC) ? "UTC" : timezone.getId();
        StringBuilder builder = new StringBuilder().append('<')
            .append(indexNamePrefix)
            .append('{')
            .append(formatter.format(dateTime))
            .append("||/")
            .append(dateRounding)
            .append('{')
            .append(indexNameFormat)
            .append('|')
            .append(zone)

View on GitHub (pinned to db6a809a66)

Solutions

1. Add the matching format string to the processor's 'date_formats' array (use 'ISO8601' for standard, 'UNIX'/'UNIX_MS' for epoch, or an explicit java-time pattern).
2. Inspect the suppressed exceptions on the thrown IllegalArgumentException to see why each parser rejected the value.
3. Normalize the date with a script/gsub processor before date_index_name if the producer cannot be changed.

Example fix

// before - input field value is epoch seconds 1700000000, default format fails
{"date_index_name": {"field": "ts", "index_name_prefix": "logs-", "date_rounding": "d"}}
// after - declare epoch format
{"date_index_name": {"field": "ts", "index_name_prefix": "logs-", "date_rounding": "d", "date_formats": ["UNIX"]}}

// In a script processor, attempt a known format and fall back to others before date_index_name:
{"script": {"source": "try { ZonedDateTime.parse(ctx.ts); } catch (Exception e) { /* leave for on_failure */ throw e; }"}}

// Pipeline on_failure to retry with a different format or quarantine:
{"on_failure": [{"date_index_name": {"field": "ts", "date_formats": ["UNIX"], "index_name_prefix": "logs-", "date_rounding": "d"}}]}

When it happens

Trigger: A date_index_name processor whose 'date_formats' list (default 'yyyy-MM-dd\'T\'HH:mm:ss.SSSXX') does not match any format present in the input field value. All configured Joda/Java DateTimeFormatter patterns fail and dateTime remains null.

Common situations: Epoch timestamps fed without the 'ISO8601' or custom epoch format; locale-specific date strings; mismatches between the producer's date format and the pipeline's date_formats list; switching from Joda to java-time syntax during upgrades (some format tokens changed).

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

• Invalid language tag specified: {}
• unable to parse date [{}]
• invalid output format [{}]
• {} must be a valid number but was [{}]
• cache capacity must be a value greater than 0 but was {}

AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/b15c14e72c265286. Report an issue: GitHub.