prestodb/presto · error · TimestampOutOfBoundsException

seconds field of timestamp exceeds maximum supported value,

Error message

seconds field of timestamp exceeds maximum supported value, secondsWithBase: %s unitsPerSecond: %s.

What it means

Thrown by ApacheHiveTimestampDecoder.getSecondsInRequiredUnits when Math.multiplyExact overflows while converting seconds (plus base seconds) to the internal unit scale. This means the TIMESTAMP's seconds field is beyond the range representable in a Presto long. The ArithmeticException is rethrown as a TimestampOutOfBoundsException with the offending values.

Source

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

        // Truncate nanos to required units (millis / micros)
        long truncatedNanos = nanos / options.getNanosPerUnit();
        return getValueWithNanos(enableMicroPrecision, value, truncatedNanos);
    }

    private static long getSecondsInRequiredUnits(boolean enableMicroPrecision, long secondsWithBase, long unitsPerSecond)
    {
        if (!enableMicroPrecision) {
            // This can overflow/underflow, but to maintain backward compatibility this is not bounds checked.
            return secondsWithBase * unitsPerSecond;
        }
        try {
            // Overflow/underflow is detected and the code will raise error.
            return Math.multiplyExact(secondsWithBase, unitsPerSecond);
        }
        catch (ArithmeticException e) {
            String errorMessage = String.format("seconds field of timestamp exceeds maximum supported value, secondsWithBase: %s unitsPerSecond: %s.",
                    secondsWithBase, unitsPerSecond);
            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);

View on GitHub (pinned to 55bb57d202)

Solutions

Clamp or reject out-of-range timestamp values at write time so files stay within Presto's supported range.
Sanitize the source data (e.g. in the producing ETL) to valid date ranges before writing ORC.
Catch TimestampOutOfBoundsException in the reader pipeline and treat the row as null/error per policy.
If the value is legitimate, store it as VARCHAR or a scaled type instead of TIMESTAMP.

Example fix

// before
long ts = seconds; // year 12000, overflows on decode
// after
if (secondsWithBase > MAX_SUPPORTED_SECONDS) { secondsWithBase = MAX_SUPPORTED_SECONDS; }

Defensive patterns

Strategy: validation

Validate before calling

// reject seconds outside Presto's supported range before writing/reading
if (secondsWithBase > MAX_SECONDS || secondsWithBase < MIN_SECONDS) throw new IllegalArgumentException("timestamp out of range");

Try / catch

try { ts = decode(...); } catch (TimestampOutOfBoundsException e) { ts = null; /* or map to error row */ }

Prevention

Clamp timestamps to a sane range (e.g. 1900-9999) in ETL
Never store extreme epoch values as TIMESTAMP; use BIGINT if needed
Document the supported timestamp range for downstream producers

When it happens

Trigger: Decoding an ORC TIMESTAMP whose secondsWithBase * unitsPerSecond exceeds Long.MAX_VALUE/MIN_VALUE — i.e. seconds values far outside year-range Presto supports (roughly years ±290 with micro precision much narrower).

Common situations: ORC files containing extreme timestamps (year 10000+, or ancient dates) written by other systems; wrong baseSeconds/options configuration causing double-counting; decimal-style streams misread as timestamps.

Related errors

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