prestodb/presto · error · PrestoException

DECODER_CONVERSION_NOT_SUPPORTED

DECODER_CONVERSION_NOT_SUPPORTED

Error message

could not parse value '%s' as '%s' for column '%s'

What it means

RFC2822JsonFieldDecoder.getMillis parses the JSON value's text with a DateTimeFormatter for RFC 2822 date strings (e.g. 'Tue, 10 Jun 2003 04:00:00 GMT'). An IllegalArgumentException from the parser (unparseable text) is caught and rethrown as PrestoException(DECODER_CONVERSION_NOT_SUPPORTED) with the message "could not parse value '%s' as '%s' for column '%s'". It indicates the field content is not a valid RFC 2822 date.

Source

Thrown at presto-record-decoder/src/main/java/com/facebook/presto/decoder/json/RFC2822JsonFieldDecoder.java:84

    }

    public static class RFC2822JsonValueProvider
            extends AbstractDateTimeJsonValueProvider
    {
        public RFC2822JsonValueProvider(JsonNode value, DecoderColumnHandle columnHandle)
        {
            super(value, columnHandle);
        }

        @Override
        protected long getMillis()
        {
            if (value.isValueNode()) {
                try {
                    return FORMATTER.parseMillis(value.asText());
                }
                catch (IllegalArgumentException e) {
                    throw new PrestoException(
                            DECODER_CONVERSION_NOT_SUPPORTED,
                            format("could not parse value '%s' as '%s' for column '%s'", value.asText(), columnHandle.getType(), columnHandle.getName()));
                }
            }
            throw new PrestoException(
                    DECODER_CONVERSION_NOT_SUPPORTED,
                    format("could not parse non-value node as '%s' for column '%s'", columnHandle.getType(), columnHandle.getName()));
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Make the producer emit RFC 2822 dates (e.g. 'Tue, 10 Jun 2003 04:00:00 GMT').
2. Switch the column dataFormat to 'iso8601' or 'milliseconds-since-epoch' to match the actual payload format.
3. Transform the field upstream to RFC 2822 before it reaches the topic.
4. Read the field as varchar and convert with Presto's date_parse/from_unixtime functions instead.

Example fix

// before: rfc2822 decoder on ISO payload -> parse failure
-- sent_at TIMESTAMP WITH TIME ZONE WITH (data_format='rfc2822', mapping='date')
// after: use the decoder matching the wire format
-- sent_at TIMESTAMP WITH TIME ZONE WITH (data_format='iso8601', mapping='date')

// Validate the date string looks RFC2822 before relying on the decoder:
boolean isRfc2822(String v) {
  return v != null && v.matches("[A-Za-z]{3}, \\d{1,2} [A-Za-z]{3} \\d{4} \\d{2}:\\d{2}:\\d{2} (GMT|[+-]\\d{4})");
}

try (ResultSet rs = stmt.executeQuery(sql)) { ... } catch (SQLException e) { if (e.getMessage().contains("could not parse value") && e.getMessage().contains("rfc")) { switchColumnToIso8601(); } else throw e; }

When it happens

Trigger: Column with dataFormat 'rfc2822' where the mapped JSON value node's text is not RFC2822, e.g. '{"date": "2024-01-01"}' (ISO) or '{"date": "1704067200"}' (epoch); FORMATTER.parseMillis throws IllegalArgumentException during getMillis on query execution.

Common situations: Producer emits ISO-8601 or epoch values while the table was defined with the rfc2822 decoder; email-style headers changed format; locale/zone suffixes missing from the date string.

Related errors

• DECODER_CONVERSION_NOT_SUPPORTED
• DECODER_CONVERSION_NOT_SUPPORTED
• LANCE_ERROR
• INVALID_CAST_ARGUMENT
• INVALID_FUNCTION_ARGUMENT

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/d4bc04431e8530aa. Report an issue: GitHub.