prestodb/presto · error · TimestampOutOfBoundsException

Timestamp exceeds maximum supported value, value: %s truncat

Error message

Timestamp exceeds maximum supported value, value: %s truncatedNanos: %s.

What it means

Thrown by ApacheHiveTimestampDecoder.getValueWithNanos when Math.addExact overflows adding truncated nanos to the seconds value. It indicates the composed timestamp cannot be represented in Presto's internal long-based timestamp representation, and is rethrown as TimestampOutOfBoundsException.

Source

Thrown at presto-orc/src/main/java/com/facebook/presto/orc/reader/ApacheHiveTimestampDecoder.java:77

            throw new TimestampOutOfBoundsException(errorMessage, e);
        }
    }

    // Add truncated nanos to seconds value
    private static long getValueWithNanos(boolean enableMicroPrecision, long value, long truncatedNanos)
    {
        if (!enableMicroPrecision) {
            // This can overflow/underflow, but to maintain backward compatibility this is not bounds checked.
            return value + truncatedNanos;
        }
        try {
            // Overflow/underflow is detected and the code will raise error.
            return Math.addExact(value, truncatedNanos);
        }
        catch (ArithmeticException e) {
            String errorMessage = String.format("Timestamp exceeds maximum supported value, value: %s truncatedNanos: %s.",
                    value, truncatedNanos);
            throw new TimestampOutOfBoundsException(errorMessage, e);
        }
    }

    // This comes from the Apache Hive ORC code
    private static int parseNanos(long serialized)
    {
        int zeros = ((int) serialized) & 0b111;
        int result = (int) (serialized >>> 3);
        if (zeros != 0) {
            for (int i = 0; i <= zeros; ++i) {
                result *= 10;
            }
        }
        return result;
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Keep timestamp data within the supported range (avoid values near the internal long limits).
Normalize extreme values in the ETL layer before writing ORC files.
Catch TimestampOutOfBoundsException and substitute a sentinel/null in the reading application.
Verify enableMicroPrecision/unitsPerSecond options match how the file was written to avoid inflated values.

Example fix

// before
Timestamp value = decoder.decodeTimestamp(...); // may throw
// after
try { value = decoder.decodeTimestamp(...); } catch (TimestampOutOfBoundsException e) { value = null; }

Defensive patterns

Strategy: try-catch

Validate before calling

// ensure seconds+nanos composition stays within long range before decode
if (secondsWithBase >= MAX_SECONDS - 1) throw new IllegalArgumentException("timestamp too large");

Try / catch

try { ts = decoder.decodeTimestamp(...); } catch (TimestampOutOfBoundsException e) { ts = null; }

Prevention

Keep timestamps well inside the supported long range
Normalize out-of-range data in upstream ETL
Match enableMicroPrecision/unitsPerSecond options to the file encoding

When it happens

Trigger: decodeTimestamp producing a value so close to Long.MAX_VALUE (or MIN_VALUE) that adding the nanos component overflows — practically only with seconds already near the representable limit.

Common situations: ORC timestamps at the extreme edge of the supported range; negative pre-epoch timestamps near Long.MIN_VALUE combined with nanos handling; misaligned unit scaling between writer and reader options.

Related errors

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