prestodb/presto · error · UnsupportedOperationException

Unsupported precision for TimeUnit conversion: TIMESTAMP(

Error message

Unsupported precision for TimeUnit conversion: TIMESTAMP(

What it means

The private toTimeUnit helper maps a TIMESTAMP precision to a java.util.concurrent.TimeUnit, but only the default precision (3 -> MILLISECONDS) and MAX_SHORT_PRECISION (6 -> MICROSECONDS) have a TimeUnit equivalent. Any other precision cannot be expressed as a TimeUnit, so UnsupportedOperationException is thrown.

Source

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

        }
        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;
        }
        throw new UnsupportedOperationException(
                "Unsupported precision for TimeUnit conversion: TIMESTAMP(" + precision + ")");
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Avoid getObjectValue for non-3/6 precisions; use getLong plus explicit conversion.
Change the column to TIMESTAMP(3) or TIMESTAMP(6) if an Object/TimeUnit-based representation is required.
Convert manually using getEpochSecond/getNanos instead of relying on TimeUnit mapping.

Example fix

// before
Object v = type.getObjectValue(props, block, pos); // TIMESTAMP(0)
// after
long epochSecond = type.getEpochSecond(type.getLong(block, pos));
int nanos = type.getNanos(type.getLong(block, pos));

Defensive patterns

Strategy: validation

Validate before calling

if (!(type.getPrecision() == 3 || type.getPrecision() == 6)) {
    throw new IllegalStateException("TimeUnit mapping only supports TIMESTAMP(3)/(6): " + type.getPrecision());
}

Type guard

boolean hasTimeUnitMapping(TimestampType t) { return t.getPrecision() == 3 || t.getPrecision() == 6; }

Try / catch

try {
    value = type.getObjectValue(props, block, pos);
} catch (UnsupportedOperationException e) {
    value = manualEpochConversion(type.getLong(block, pos));
}

Prevention

Do not rely on getObjectValue/TimeUnit for precisions other than 3 and 6.
Use getEpochSecond/getNanos for explicit unit conversions.
Standardize column precision on 3 or 6 in schemas clients materialize as objects.

When it happens

Trigger: Indirectly triggered by getObjectValue (and other helpers) on a TimestampType whose precision is neither 3 nor 6 — e.g. TIMESTAMP(0) or TIMESTAMP(9).

Common situations: Client materialization of TIMESTAMP(0) columns (a common schema choice) through getObjectValue; code hitting this after schemas changed 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/732a800f4ac3e996. Report an issue: GitHub.