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
- Supply epoch milliseconds that fit in a signed 64-bit long (e.g. 1700000000000).
- Drop the quotes/numeric form and use a standard date string like '2024-01-15 10:30:00+0000' instead.
- Strip invalid characters (spaces, separators) before parsing.
- 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
- Pass Date objects or epoch-millis longs via bound statements instead of parsing strings.
- Use accepted formats: epoch millis or 'yyyy-MM-dd HH:mm:ss+0000'.
- Avoid timestamps from other systems with non-millisecond units.
- Normalize 'T'-separated ISO strings before parsing.
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
- Cannot parse 32-bits int value from "%s"
- Cannot parse date value from "%s"
- Cannot parse time value from "%s"
- Invalid 32-bits integer value, expecting 4 bytes but got %d
- time values must be enclosed by single quotes
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/17aaccfc9bdcb7db.
Report an issue: GitHub.