prestodb/presto · error · PrestoException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

Unsupported representation for field '%s' of type TIMESTAMP: %s [%s]

What it means

TimestampDecoder supports timestamps represented as ISO-8601 strings (parsed with ISO_DATE_TIME) or epoch-millisecond numbers. Any other representation (boolean, object, array, or a non-ISO string shape) is rejected with NOT_SUPPORTED because the decoder cannot deterministically convert it to LocalDateTime.

Source

Thrown at presto-elasticsearch/src/main/java/com/facebook/presto/elasticsearch/decoders/TimestampDecoder.java:81

            }
            String valueString = documentField.toJson().asJsonArray().get(0).toString();
            value = valueString.replace("\"", "");
        }

        if (value == null) {
            output.appendNull();
            return;
        }

        LocalDateTime timestamp;
        if (value instanceof String) {
            timestamp = ISO_DATE_TIME.parse((String) value, LocalDateTime::from);
        }
        else if (value instanceof Number) {
            timestamp = LocalDateTime.ofInstant(Instant.ofEpochMilli(((Number) value).longValue()), ZULU);
        }
        else {
            throw new PrestoException(NOT_SUPPORTED, format(
                    "Unsupported representation for field '%s' of type TIMESTAMP: %s [%s]",
                    path,
                    value.getClass().getSimpleName(),
                    value));
        }

        long epochMillis = timestamp.atZone(zoneId)
                .toInstant()
                .toEpochMilli();

        TIMESTAMP.writeLong(output, epochMillis);
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Normalize the field in the documents to an ISO-8601 string ("2024-01-01T00:00:00") or epoch millis number, then reindex.
Use an ingest pipeline script to convert formats (e.g. multiply epoch seconds by 1000 and output as long).
Map the Presto column as VARCHAR/JSON and parse with date_parse/from_unixtime in SQL.

Example fix

// before
{"ts": {"$date": "2024-01-01T00:00:00Z"}}
// after
{"ts": "2024-01-01T00:00:00"}

Defensive patterns

Strategy: validation

Validate before calling

function isSupportedTimestamp(v) {
  if (typeof v === 'number') return true; // epoch millis
  if (typeof v !== 'string') return false;
  return /^\d{4}-\d{2}-\d{2}(T[0-2]\d:[0-5]\d(:[0-5]\d(\.\d+)?)?(Z|[+-]\d{2}:\d{2})?)?$/.test(v);
}

Type guard

function isIsoStringOrEpochMillis(v) { return typeof v === 'number' || (typeof v === 'string' && !Number.isNaN(Date.parse(v))); }

Try / catch

try { SELECT ts FROM "idx" } catch (PrestoException e) { if (e.getErrorCode().getName().equals("NOT_SUPPORTED")) { /* map as VARCHAR and parse with date_parse/from_unixtime */ } throw e; }

Prevention

Store timestamps as ISO-8601 strings or epoch milliseconds only.
Convert extended JSON like {"$date": ...} to plain strings at ingest.
Remember the decoder expects epoch MILLIS; convert seconds by multiplying by 1000.
Map the Elasticsearch field as date so indexing validates the format.

When it happens

Trigger: decode() sees a value that is neither String nor Number for a TIMESTAMP-mapped field, e.g. {"ts": true}, {"ts": {"$date": ...}}, or an epoch-seconds float/decimal string like "1700000000.123".

Common situations: Documents written by MongoDB-style drivers use extended JSON {"$date": ...} objects; epoch values in seconds (not milliseconds) stored as strings; arrays from multi-valued mapping after the size check passed at exactly 1.

Understand the failure class

Background: Presto NOT_SUPPORTED error: what "not supported" means and how to fix it — this error's family across 3 libraries.

Related errors

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