apache/cassandra · error · InvalidTypeException

Cannot parse timestamp value from "%s"

Error message

Cannot parse timestamp value from "%s"

What it means

Thrown by TypeCodec.TimestampCodec.parse(String) when the string looks like a numeric long literal (isLongLiteral), but Long.parseLong fails or (conceptually) the numeric form is invalid — i.e. the quoted value overflows a long or is malformed, so it cannot become a Date from epoch millis. The library converts CQL timestamp literals either from epoch milliseconds (long) or from date/time strings; this branch handles the numeric one.

Source

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

            return 8;
        }

        @Override
        public Date parse(String value)
        {
            if (value == null || value.isEmpty() || value.equalsIgnoreCase("NULL")) return null;
            // strip enclosing single quotes, if any
            if (ParseUtils.isQuoted(value)) value = ParseUtils.unquote(value);

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

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

        @Override
        public String format(Date value)
        {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Supply epoch milliseconds that fit in a signed 64-bit long (e.g. 1700000000000).
  2. Drop the quotes/numeric form and use a standard date string like '2024-01-15 10:30:00+0000' instead.
  3. Strip invalid characters (spaces, separators) before parsing.
  4. Catch InvalidTypeException and re-prompt/convert the input with a proper timestamp parser.

Example fix

// before
Date d = TypeCodec.timestamp().parse("'2024-01-15T10:30:00Z'"); // parsed as long literal branch? no—use proper form
// after
Date d = TypeCodec.timestamp().parse("'1705314600000'");
// or, preferably, a date string:
Date d2 = TypeCodec.timestamp().parse("'2024-01-15 10:30:00+0000'");
Defensive patterns

Strategy: validation

Validate before calling

static boolean isValidEpochMillis(String s) {
    String t = s == null ? "" : s.trim();
    try { long ms = Long.parseLong(t); return ms >= Long.MIN_VALUE; } catch (NumberFormatException e) { return false; }
}

Try / catch

try {
    Date d = TypeCodec.timestamp().parse(literal);
} catch (InvalidTypeException e) {
    log.warn("Bad timestamp literal: {}", literal);
    d = new Date(System.currentTimeMillis()); // or surface a validation error
}

Prevention

When it happens

Trigger: Calling TimestampCodec.parse() with a quoted numeric string that overflows long range (e.g. "99999999999999999999") or contains characters that look numeric to isLongLiteral but fail parseLong; parse is reached only when isLongLiteral(value) is true.

Common situations: Timestamps copied from other systems in units other than millis (seconds/micros) padded with digits beyond long range; hand-built literals with stray signs or underscores; users typing full-precision timestamps from other languages into cqlsh-style literals.

Related errors


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