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

AbstractDateTimeJsonValueProvider.getLong() converts a JSON datetime value to epoch millis via getMillis(), then range-checks it against the column type. For TIME/TIME_WITH_TIME_ZONE columns the millis value must be within one day [0, 86399999); if the parsed value falls outside, DECODER_CONVERSION_NOT_SUPPORTED is thrown. The value parsed as a duration/time-of-day is invalid for the target TIME column.

Source

Thrown at presto-record-decoder/src/main/java/com/facebook/presto/decoder/json/AbstractDateTimeJsonValueProvider.java:60

        this.columnHandle = columnHandle;
    }

    @Override
    public final boolean isNull()
    {
        return value.isMissingNode() || value.isNull();
    }

    @Override
    public final long getLong()
    {
        long millis = getMillis();

        Type type = columnHandle.getType();

        if (type == TIME || type == TIME_WITH_TIME_ZONE) {
            if (millis < 0 || millis >= TimeUnit.DAYS.toMillis(1)) {
                throw new PrestoException(
                        DECODER_CONVERSION_NOT_SUPPORTED,
                        format("could not parse value '%s' as '%s' for column '%s'", value.asText(), columnHandle.getType(), columnHandle.getName()));
            }
        }

        if (type.equals(DATE)) {
            return TimeUnit.MILLISECONDS.toDays(millis);
        }
        if (type.equals(TIMESTAMP) || type.equals(TIME)) {
            return millis;
        }
        if (type.equals(TIMESTAMP_WITH_TIME_ZONE) || type.equals(TIME_WITH_TIME_ZONE)) {
            return packDateTimeWithZone(millis, 0);
        }

        return millis;
    }

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Change the column type to TIMESTAMP/TIMESTAMP_WITH_TIME_ZONE if the source carries full timestamps
  2. Extract only the time-of-day component (e.g. via format hint or JSON path) so millis stays within [0, 86400000)
  3. Validate/normalize the JSON values upstream to match the declared column type
  4. Check the format hint pattern so parsing yields the intended time-of-day millis

Example fix

// before
{"name": "event_time", "type": "time", "mapping": "$.ts"}  // $.ts = '2024-05-01T10:30:00Z'
// after
{"name": "event_time", "type": "timestamp", "mapping": "$.ts"}
Defensive patterns

Strategy: validation

Validate before calling

boolean fitsTimeColumn(long millis) {
    return millis >= 0 && millis < TimeUnit.DAYS.toMillis(1);
}
// check fitsTimeColumn(parsedMillis) when the column is declared TIME/TIME_WITH_TIME_ZONE

Try / catch

try { row.getLong(columnName); }
catch (PrestoException e) {
    if (e.getErrorCode().getName().equals("DECODER_CONVERSION_NOT_SUPPORTED")) {
        log.warn("Time-of-day out of range for TIME column {}", columnName); return null;
    }
    throw e;
}

Prevention

When it happens

Trigger: JSON value parses to a full timestamp (with date component) or an epoch far beyond one day, but the column is declared TIME or TIME_WITH_TIME_ZONE; negative millis from dates before epoch parsed as time-of-day.

Common situations: Declaring a column TIME while the JSON feed contains '2024-01-01T10:30:00' timestamps; timezone offsets pushing parsed millis negative; schema evolution changed the source field from time-only to full timestamp.

Related errors

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