prestodb/presto · error · PrestoException

NUMERIC_VALUE_OUT_OF_RANGE

NUMERIC_VALUE_OUT_OF_RANGE

Error message

NUMERIC_VALUE_OUT_OF_RANGE: e.getMessage()

What it means

The same currentTime() function also catches ArithmeticException from packDateTimeWithZone (e.g. overflow while packing millis into the packed datetime-with-zone representation) and rethrows it as PrestoException NUMERIC_VALUE_OUT_OF_RANGE. It means the computed time value overflowed the range representable by Presto's packed long encoding.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/operator/scalar/DateTimeFunctions.java:136

        long millis = UTC_CHRONOLOGY.millisOfDay().get(properties.getSessionStartTime());

        // However, those UTC millis are pointing to the correct UTC timestamp
        // Our TIME WITH TIME ZONE representation does use UTC 1970-01-01 representation
        // So we have to hack here in order to get valid representation
        // of TIME WITH TIME ZONE
        millis -= valueToSessionTimeZoneOffsetDiff(properties.getSessionStartTime(), getDateTimeZone(properties.getTimeZoneKey()));

        try {
            return packDateTimeWithZone(millis, properties.getTimeZoneKey());
        }
        catch (NotSupportedException | TimeZoneNotSupportedException e) {
            throw new PrestoException(NOT_SUPPORTED, e.getMessage(), e);
        }
        catch (IllegalArgumentException e) {
            throw new PrestoException(INVALID_FUNCTION_ARGUMENT, e.getMessage(), e);
        }
        catch (ArithmeticException e) {
            throw new PrestoException(NUMERIC_VALUE_OUT_OF_RANGE, e.getMessage(), e);
        }
    }

    @Description("current time without time zone")
    @ScalarFunction("localtime")
    @SqlType(StandardTypes.TIME)
    public static long localTime(SqlFunctionProperties properties)
    {
        if (properties.isLegacyTimestamp()) {
            long millis = UTC_CHRONOLOGY.millisOfDay().get(properties.getSessionStartTime());
            return millis - valueToSessionTimeZoneOffsetDiff(properties.getSessionStartTime(), getDateTimeZone(properties.getTimeZoneKey()));
        }
        ISOChronology localChronology = getChronology(properties.getTimeZoneKey());
        return localChronology.millisOfDay().get(properties.getSessionStartTime());
    }

    @Description("current time zone")
    @ScalarFunction("current_timezone")

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Check coordinator/worker system clock sanity (NTP-synced); restart the coordinator if sessionStartTime is corrupted.
  2. Re-run the query in a new session; a fresh session start time may avoid the bad value.
  3. Validate the JVM tz/Joda-time setup, since chronology arithmetic overflow often stems from bad zone data.
  4. If in a test harness, pass a realistic sessionStartTime within [0, 86400000) millis-of-day.

Example fix

// before (test harness)
props.setSessionStartTime(Long.MAX_VALUE);
// after
props.setSessionStartTime(System.currentTimeMillis());
Defensive patterns

Strategy: try-catch

Validate before calling

// Ensure clocks are sane before issuing time queries:
long skew = Math.abs(System.currentTimeMillis() - serverReportedMillis);
if (skew > 86_400_000L) throw new IllegalStateException("coordinator clock out of range");

Try / catch

catch (SQLException e) {
    if (e.getMessage().contains("NUMERIC_VALUE_OUT_OF_RANGE")) {
        // retry with a fresh session / recalibrate clock, then re-run
        reconnect();
    } else { throw e; }
}

Prevention

When it happens

Trigger: SELECT current_time() when millis derived from the session start time overflows during packDateTimeWithZone arithmetic (ArithmeticException from Joda-time/long packing).

Common situations: Corrupted or wildly out-of-range sessionStartTime in properties; clock misconfiguration on the coordinator; synthetic/test harnesses injecting extreme values.

Related errors

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