prestodb/presto · error · PrestoException

INVALID_FUNCTION_ARGUMENT

INVALID_FUNCTION_ARGUMENT

Error message

INVALID_FUNCTION_ARGUMENT: e.getMessage()

What it means

Presto's currentTime() (current_time SQL function) packs the session start time with the session time zone via packDateTimeWithZone. When that packing throws IllegalArgumentException (invalid millisecond/time-zone combination), the function rethrows it as a PrestoException with code INVALID_FUNCTION_ARGUMENT, carrying the underlying exception's message. It signals the runtime datetime value could not be represented as a TIME WITH TIME ZONE.

Source

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

    {
        // We do all calculation in UTC, as session.getStartTime() is in UTC
        // and we need to have UTC millis for packDateTimeWithZone
        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());
    }

View on GitHub (pinned to 55bb57d202)

Solutions

1. Check the session time zone (SELECT current_timezone()) and set a valid IANA zone with SET TIME ZONE 'UTC' or a valid region/city ID.
2. Verify the coordinator/worker JVM time-zone database is intact (not stripped in minimal containers); use a full JDK image.
3. If you control the code, ensure millis passed to packDateTimeWithZone is a valid millis-of-day; clamp to [0, 86400000).
4. Upgrade Presto if the zone key fails despite being a valid IANA ID (older tz database).

Example fix

// before (session)
SET TIME ZONE 'PST8PDTX'; -- invalid id
// after
SET TIME ZONE 'America/Los_Angeles';

// Before relying on current_time, verify the session zone resolves:
String tz = client.getSessionTimeZone(); // e.g. from SHOW SESSION or connection props
if (tz == null || !isValidIanaId(tz)) {
    client.execute("SET TIME ZONE 'UTC'");
}

boolean isValidIanaId(String id) {
    try { java.time.ZoneId.of(id); return true; }
    catch (java.time.DateTimeException e) { return false; }
}

// JDBC
try (Statement s = conn.createStatement()) {
    try (ResultSet rs = s.executeQuery("SELECT current_time")) { ... }
} catch (SQLException e) {
    if (e.getMessage().contains("INVALID_FUNCTION_ARGUMENT")) {
        conn.createStatement().execute("SET TIME ZONE 'UTC'");
    } else { throw e; }
}

When it happens

Trigger: Calling SELECT current_time() (or current_time) when packDateTimeWithZone(millis, properties.getTimeZoneKey()) throws IllegalArgumentException — e.g. an unresolvable or invalid session time zone key producing an unrepresentable millis-of-day value.

Common situations: Sessions started with a bogus or misconfigured session time zone; JVM/ICU tz database mismatches after upgrades; misconfigured server.time-zone or session SET TIME ZONE values.

Related errors

• NUMERIC_VALUE_OUT_OF_RANGE
• INVALID_FUNCTION_ARGUMENT
• Timeout is negative
• INVALID_FUNCTION_ARGUMENT
• GENERIC_INTERNAL_ERROR

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