apache/cassandra · error · MarshalException

Unable to make long (for date) from: '%s'

Error message

Unable to make long (for date) from: '%s'

What it means

TimestampSerializer.dateStringToTimestamp, when the input does not look like a date string, attempts to parse it as a plain long (epoch milliseconds). This error means the string is numeric-looking (starts with a digit or +/-) but not a valid long, so it cannot be interpreted as an epoch-millis timestamp.

Source

Thrown at src/java/org/apache/cassandra/serializers/TimestampSerializer.java:162

    {
        return value == null ? ByteBufferUtil.EMPTY_BYTE_BUFFER : ByteBufferUtil.bytes(value.getTime());
    }

    public static long dateStringToTimestamp(String source) throws MarshalException
    {
        if (source.equalsIgnoreCase("now"))
            return currentTimeMillis();

        // Milliseconds since epoch?
        if (timestampPattern.matcher(source).matches())
        {
            try
            {
                return Long.parseLong(source);
            }
            catch (NumberFormatException e)
            {
                throw new MarshalException(String.format("Unable to make long (for date) from: '%s'", source), e);
            }
        }

        for (DateTimeFormatter fmt: dateFormatters)
        {
            try
            {
                return ZonedDateTime.parse(source, fmt).toInstant().toEpochMilli();
            }
            catch (DateTimeParseException e)
            {
                continue;
            }
        }
        throw new MarshalException(String.format("Unable to parse a date/time from '%s'", source));
    }

    public static Format getJsonDateFormatter()

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Pass a plain integer string of epoch milliseconds, e.g. '1286598400000'
2. Convert nanos/micros to millis: String.valueOf(nanos / 1_000_000)
3. Or pass an ISO-8601 date/time string instead, e.g. '2015-05-03 13:30:54.234' — the formatter loop will parse it
4. Trim the string; remove fractional part or rounding to whole millis

Example fix

// before
session.execute("INSERT INTO t (ts) VALUES (?)", "1694000000.5");
// after
session.execute("INSERT INTO t (ts) VALUES (?)", "1694000000500");

if (input.matches("^[+-]?\\d+$")) {
  try { Long.parseLong(input.trim()); } catch (NumberFormatException e) { throw new IllegalArgumentException("numeric timestamp overflows long: " + input); }
}

boolean isParsableEpochMillis(String s) {
  try { long v = Long.parseLong(s.trim()); return true; } catch (NumberFormatException e) { return false; }
}

try {
  Date ts = TimestampSerializer.dateStringToTimestamp(input);
} catch (MarshalException e) {
  throw new BadRequestException("timestamp must be epoch-millis long or ISO-8601 string");
}

When it happens

Trigger: Passing numeric strings that overflow long (e.g. 20+ digit numbers), decimals like '1694000000.5', or numbers with separators/underscores into a timestamp column; also strings starting with digits but containing letters.

Common situations: High-precision epoch values from other systems (nanos/micros since epoch) overflowing the millis long; timestamps with fractional seconds passed as strings; locale-formatted numbers with thousand separators.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

• Unable to make unsigned int (for date) from: '%s'
• Unable to parse a date/time from '%s'
• Expected 8 or 0 byte long for date (%d)
• Not enough bytes to read size of %dth field %s
• Not enough bytes to read %dth field %s

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