prestodb/presto · error · PrestoException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

NOT_SUPPORTED: e.getMessage()

What it means

current_time / current_timestamp resolution can fail when the session time zone key is not supported by the underlying date/time library (NotSupportedException or TimeZoneNotSupportedException). Presto wraps these as NOT_SUPPORTED, propagating the underlying message.

Source

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

    @ScalarFunction
    @SqlType(StandardTypes.TIME_WITH_TIME_ZONE)
    public static long currentTime(SqlFunctionProperties properties)
    {
        // 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()));
        }

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Set the session time zone to a valid IANA zone ID (e.g. America/Los_Angeles)
  2. Update the Presto/time-tzdata version so the zone is supported, or pick an equivalent supported zone
  3. Catch NOT_SUPPORTED and fall back to UTC in the client

Example fix

// before
SET SESSION time_zone = 'PST8PDT';
SELECT current_time;
// after
SET SESSION time_zone = 'America/Los_Angeles';
SELECT current_time;
Defensive patterns

Strategy: try-catch

Validate before calling

ZoneId.of(tz); // throws if unknown

Try / catch

catch (PrestoException e) { if (e.getErrorCode().getName().equals("NOT_SUPPORTED")) fallbackToUtc(); else throw e; }

Prevention

When it happens

Trigger: Session time zone set to a zone ID the Joda/ICU backend cannot resolve (custom or removed zone IDs); using current_time with such a session start time.

Common situations: Clients setting SET SESSION time_zone to a non-IANA id or an alias dropped in newer tzdata; shared queries moved between clusters with different tzdata versions.

Understand the failure class

Background: Presto NOT_SUPPORTED error: what "not supported" means and how to fix it — this error's family across 3 libraries.

Related errors

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