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
- Validate that startField is one of DAY/HOUR/MINUTE/SECOND and end is the same field or a valid subsequent sub-field before calling
- Route YEAR/MONTH combinations to parseYearMonthInterval instead
- Fix the SQL literal so its qualifier matches its content, e.g. INTERVAL '1 02:03' DAY TO MINUTE
- 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
- Route YEAR/MONTH qualifiers to parseYearMonthInterval instead
- Enforce start field <= end field in the DAY<HH<MM<SS hierarchy
- Validate user-supplied interval qualifiers against the allowed list before parsing
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
- Invalid year month interval qualifier: to
- INVALID_FUNCTION_ARGUMENT
- Invalid timestamp '%s'
- Invalid time '%s'
- Invalid interval qualifier: to
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/0388b40d97ee8747.
Report an issue: GitHub.