apache/cassandra · error · InvalidTypeException

Cannot parse time value from "%s"

Error message

Cannot parse time value from "%s"

What it means

Thrown by TypeCodec.TimeCodec.parse(String) when the quoted value's inner text looks like a long literal but Long.parseLong fails — e.g. a number out of long range or containing characters that slipped past isLongLiteral. Time values are nanoseconds within one day (0..86399999999999), and this branch converts the quoted numeric form to a java Long.

Source

Thrown at src/java/org/apache/cassandra/cql3/functions/types/TypeCodec.java:1911

        @Override
        public Long parse(String value)
        {
            if (value == null || value.isEmpty() || value.equalsIgnoreCase("NULL")) return null;

            // enclosing single quotes required, even for long literals
            if (!ParseUtils.isQuoted(value))
                throw new InvalidTypeException("time values must be enclosed by single quotes");
            value = value.substring(1, value.length() - 1);

            if (ParseUtils.isLongLiteral(value))
            {
                try
                {
                    return Long.parseLong(value);
                }
                catch (NumberFormatException e)
                {
                    throw new InvalidTypeException(
                    String.format("Cannot parse time value from \"%s\"", value), e);
                }
            }

            try
            {
                return ParseUtils.parseTime(value);
            }
            catch (ParseException e)
            {
                throw new InvalidTypeException(
                String.format("Cannot parse time value from \"%s\"", value), e);
            }
        }

        @Override
        public String format(Long value)
        {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Supply a valid nanoseconds count within 0..86399999999999, quoted, e.g. "'30600000000000'" for 08:30.
  2. Use the string form "'HH:MM:SS[.fff]'" instead of a numeric literal.
  3. Clamp/convert units (millis*1_000_000) before parsing and assert the range.
  4. Catch InvalidTypeException and validate the range in code, then construct the Long directly for bound statements.

Example fix

// before
Long t = TypeCodec.time().parse("'99999999999999999999'");
// after
long nanos = TimeUnit.HOURS.toNanos(8) + TimeUnit.MINUTES.toNanos(30);
Long t = TypeCodec.time().parse("'" + nanos + "'"); // or bind the Long directly
Defensive patterns

Strategy: validation

Validate before calling

static boolean isValidNanosOfDay(long n) {
    return n >= 0 && n <= 86_399_999_999_999L;
}
static boolean isQuotedLong(String s) {
    if (s == null || s.length() < 3 || s.charAt(0) != '\'') return false;
    try { Long.parseLong(s.substring(1, s.length() - 1)); return true; } catch (NumberFormatException e) { return false; }
}

Try / catch

try {
    Long t = TypeCodec.time().parse(literal);
} catch (InvalidTypeException e) {
    log.warn("Bad time literal: {}", literal);
    throw new IllegalArgumentException("Expected quoted nanos or HH:MM:SS[.fff]");
}

Prevention

When it happens

Trigger: Calling TimeCodec.parse() with a quoted oversized number like "'99999999999999999999'", or a malformed numeric token inside quotes; reached only after the mandatory quoting check and when isLongLiteral(inner) is true.

Common situations: Milliseconds/microseconds mistakenly supplied where nanoseconds are expected (unit confusion with overflow guard-rails); concatenated literals with stray characters; generated values exceeding the day range and long-range typos.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/9c2814a78fa30a6d. Report an issue: GitHub.