prestodb/presto · error · IllegalArgumentException

Invalid day second interval qualifier: to

Error message

Invalid day second interval qualifier:  to 

What it means

DateTimeUtils.parseDayTimeInterval parses DAY–SECOND range interval literals (e.g. INTERVAL '1 02:03:04' DAY TO SECOND). It only accepts specific start/end field combinations (DAY, DAY TO HOUR, DAY TO MINUTE, DAY TO SECOND, HOUR..., MINUTE..., SECOND TO SECOND). Any other qualifier pair falls through to this IllegalArgumentException; note the message renders the (already printed) enum values so it may read ' to ' oddly when nulls are involved.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/util/DateTimeUtils.java:489

        if (startField == IntervalField.HOUR && end == IntervalField.MINUTE) {
            return parsePeriodMillis(INTERVAL_HOUR_MINUTE_FORMATTER, value, startField, end);
        }
        if (startField == IntervalField.HOUR && end == IntervalField.HOUR) {
            return parsePeriodMillis(INTERVAL_HOUR_FORMATTER, value, startField, end);
        }

        if (startField == IntervalField.MINUTE && end == IntervalField.SECOND) {
            return parsePeriodMillis(INTERVAL_MINUTE_SECOND_FORMATTER, value, startField, end);
        }
        if (startField == IntervalField.MINUTE && end == IntervalField.MINUTE) {
            return parsePeriodMillis(INTERVAL_MINUTE_FORMATTER, value, startField, end);
        }

        if (startField == IntervalField.SECOND && end == IntervalField.SECOND) {
            return parsePeriodMillis(INTERVAL_SECOND_FORMATTER, value, startField, end);
        }

        throw new IllegalArgumentException("Invalid day second interval qualifier: " + startField + " to " + end);
    }

    public static long parsePeriodMillis(PeriodFormatter periodFormatter, String value, IntervalField startField, IntervalField endField)
    {
        try {
            Period period = parsePeriod(periodFormatter, value);
            return IntervalDayTime.toMillis(
                    period.getValue(DAY_FIELD),
                    period.getValue(HOUR_FIELD),
                    period.getValue(MINUTE_FIELD),
                    period.getValue(SECOND_FIELD),
                    period.getValue(MILLIS_FIELD));
        }
        catch (IllegalArgumentException e) {
            throw invalidInterval(e, value, startField, endField);
        }
    }

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Validate that startField is one of DAY/HOUR/MINUTE/SECOND and end is the same field or a valid subsequent sub-field before calling
  2. Route YEAR/MONTH combinations to parseYearMonthInterval instead
  3. Fix the SQL literal so its qualifier matches its content, e.g. INTERVAL '1 02:03' DAY TO MINUTE
  4. Check call sites for swapped start/end arguments

Example fix

// before
parseDayTimeInterval(value, IntervalField.SECOND, IntervalField.DAY); // invalid: reversed
// after
parseDayTimeInterval(value, IntervalField.DAY, IntervalField.SECOND);
Defensive patterns

Strategy: validation

Validate before calling

boolean valid = start == IntervalField.DAY || start == IntervalField.HOUR || start == IntervalField.MINUTE || start == IntervalField.SECOND;
boolean ordered = valid && end.ordinal() >= start.ordinal() && end != IntervalField.YEAR && end != IntervalField.MONTH;

Try / catch

try { return parseDayTimeInterval(value, start, end); } catch (IllegalArgumentException e) { throw new InvalidInputException("Unsupported DAY-SECOND qualifier: " + start + " to " + end); }

Prevention

When it happens

Trigger: Calling parseDayTimeInterval with a start/end IntervalField combination that is not a legal DAY-SECOND qualifier, e.g. startField=YEAR or MONTH on this code path, or end field that precedes/doesn't follow start (such as SECOND to DAY).

Common situations: Programmatic construction of interval literals from user input without validating field ranges; grammar/AST changes routing YEAR-MONTH intervals into the day-second parser by mistake; user SQL like INTERVAL '3' YEAR TO MONTH hitting the wrong parser.

Related errors


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