prestodb/presto · error · IllegalArgumentException

TIMESTAMP precision must be in range [0, %d]: %d

Error message

TIMESTAMP precision must be in range [0, %d]: %d

What it means

TimestampType.createTimestampType only accepts a precision between 0 and MAX_PRECISION (12). Precision values outside that range cannot be represented as a Presto TIMESTAMP type, so the factory interns the instance only after validating the range and throws IllegalArgumentException otherwise.

Source

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

            INSTANCES[p] = new TimestampType(p);
        }
    }

    public static final TimestampType TIMESTAMP = INSTANCES[DEFAULT_PRECISION];

    // Keeps the legacy "timestamp microseconds" type signature so existing code that matches
    // on type-signature base strings continues to work without changes.
    public static final TimestampType TIMESTAMP_MICROSECONDS = INSTANCES[MAX_SHORT_PRECISION];

    private final int precision;

    // Returns the interned instance for p=0..MAX_PRECISION. Only p=3 and p=6 are registered in
    // the type manager; all other precisions are arithmetic-only until a follow-up change wires
    // full type-system support (see github.com/prestodb/presto/issues/27934).
    public static TimestampType createTimestampType(int precision)
    {
        if (precision < 0 || precision > MAX_PRECISION) {
            throw new IllegalArgumentException(format(
                    "TIMESTAMP precision must be in range [0, %d]: %d", MAX_PRECISION, precision));
        }
        return INSTANCES[precision];
    }

    private TimestampType(int precision)
    {
        super(buildTypeSignature(precision));
        this.precision = precision;
    }

    private static TypeSignature buildTypeSignature(int precision)
    {
        if (precision == DEFAULT_PRECISION) {
            // Preserve "timestamp" (no parameter) so existing serialized metadata continues to parse.
            return parseTypeSignature(StandardTypes.TIMESTAMP);
        }
        if (precision == MAX_SHORT_PRECISION) {

View on GitHub (pinned to 55bb57d202)

Solutions

1. Clamp or validate the precision argument to [0, MAX_PRECISION] before calling createTimestampType.
2. If the precision came from parsing a type string, verify the parsed value (a malformed signature may yield a wrong number).
3. Use TimestampType.TIMESTAMP / TIMESTAMP_WITH_TIME_ZONE constants for the common p=3 and p=6 cases instead of constructing manually.

Example fix

// before
TimestampType t = TimestampType.createTimestampType(precision);
// after
if (precision < 0 || precision > TimestampType.MAX_PRECISION) {
    precision = Math.min(Math.max(precision, 0), TimestampType.MAX_PRECISION);
}
TimestampType t = TimestampType.createTimestampType(precision);

if (precision < 0 || precision > TimestampType.MAX_PRECISION) {
    throw new IllegalArgumentException("precision out of range [0, " + TimestampType.MAX_PRECISION + "]: " + precision);
}

boolean isValidTimestampPrecision(int p) { return p >= 0 && p <= TimestampType.MAX_PRECISION; }

try {
    type = TimestampType.createTimestampType(p);
} catch (IllegalArgumentException e) {
    type = TimestampType.TIMESTAMP; // safe default
}

When it happens

Trigger: Calling TimestampType.createTimestampType(p) with p < 0 or p > MAX_PRECISION (e.g. -1, 13, or a precision derived from a parser that mis-reads TIMESTAMP(30)).

Common situations: Plugin/connector code constructing timestamp types from metadata strings, ORMs or codegen emitting oversized precisions, or arithmetic on precisions (e.g. p + n for derived types) drifting out of range.

Related errors

• Expected exactly one parameter for VARCHAR
• VARCHAR length must be a number
• dictionarySourceIds must be the same
• blocks is empty
• Column does not have same position count (%s) as page (%s)

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