prestodb/presto · error · UnsupportedOperationException

fromEpochComponents is not supported for TIMESTAMP(

Error message

fromEpochComponents is not supported for TIMESTAMP(

What it means

fromEpochComponents builds a packed long TIMESTAMP value from epoch seconds plus a nanos fraction, which only fits the 64-bit representation for short precisions (p=0..6). For precisions 7-12 (isShort() == false) it throws UnsupportedOperationException.

Source

Thrown at presto-common/src/main/java/com/facebook/presto/common/type/TimestampType.java:200

        }
        return getEpochSecond(timestamp) * 1_000L + getNanos(timestamp) / 1_000_000;
    }

    // Supported for all short precisions (p=0 through p=6, i.e. isShort()==true).
    // Long precisions (p=7-12) require a 128-bit representation and are not yet supported.
    public long toEpochMicros(long timestamp)
    {
        if (!isShort()) {
            throw new UnsupportedOperationException(
                    "toEpochMicros is not supported for TIMESTAMP(" + precision + ")");
        }
        return getEpochSecond(timestamp) * 1_000_000L + getNanos(timestamp) / 1_000;
    }

    public long fromEpochComponents(long epochSecond, int nanos)
    {
        if (!isShort()) {
            throw new UnsupportedOperationException(
                    "fromEpochComponents is not supported for TIMESTAMP(" + precision + ")");
        }
        if (nanos < 0 || nanos >= 1_000_000_000) {
            throw new IllegalArgumentException("nanos must be in range [0, 999_999_999]: " + nanos);
        }
        long scale = PRECISION_SCALE[precision];
        return epochSecond * scale + nanos / (1_000_000_000L / scale);
    }

    private static TimeUnit toTimeUnit(int precision)
    {
        // Exact-precision checks: DEFAULT_PRECISION (3) stores epoch-millis; MAX_SHORT_PRECISION (6)
        // stores epoch-micros. Other precisions have no direct TimeUnit mapping.
        if (precision == DEFAULT_PRECISION) {
            return MILLISECONDS;
        }
        if (precision == MAX_SHORT_PRECISION) {
            return MICROSECONDS;

View on GitHub (pinned to 55bb57d202)

Solutions

Guard with isShort() before constructing and fall back to the 128-bit builder for long precisions.
Target a TIMESTAMP(6) or lower column instead.
Compose the value via LongTimestamp/long timestamp write APIs for p=7-12.

Example fix

// before
long packed = type.fromEpochComponents(epochSecond, nanos);
// after
long packed = type.isShort()
        ? type.fromEpochComponents(epochSecond, nanos)
        : buildLongTimestamp(type, epochSecond, nanos);

Defensive patterns

Strategy: type-guard

Validate before calling

if (!timestampType.isShort()) {
    throw new IllegalStateException("fromEpochComponents requires short precision, got " + timestampType.getPrecision());
}

Type guard

boolean canBuildPackedTimestamp(TimestampType t) { return t.isShort(); }

Try / catch

try {
    packed = type.fromEpochComponents(epochSecond, nanos);
} catch (UnsupportedOperationException e) {
    packed = buildLongTimestamp(type, epochSecond, nanos);
}

Prevention

Verify isShort() before building packed values.
Use the LongTimestamp write path for p=7-12 columns.
Keep a shared helper that dispatches short vs long timestamp construction.

When it happens

Trigger: Calling fromEpochComponents(epochSecond, nanos) on a TimestampType with precision 7-12.

Common situations: Partition-transform adjustment code or connectors synthesizing timestamp values from component fields when the target column uses long precision.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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