apache/cassandra · error · RuntimeException

Unable to parse restore target time

Error message

Unable to parse restore target time

What it means

Thrown when the 'restore_point_in_time' property in commitlog_archiving.properties cannot be parsed as a date-time string. Cassandra parses it with a DateTimeParseException wrapper, so the string must be in a format accepted by its time parser (ISO-8601 style).

Solutions

1. Use an ISO-8601 timestamp, e.g. restore_point_in_time: 2024-01-15T10:00:00+00:00 (or the format documented for your Cassandra version).
2. Remove the property (restore will use Long.MAX_VALUE, i.e. restore everything available).
3. Validate the timestamp by parsing it with java.time (OffsetDateTime/DateTimeFormatter) before deployment.
4. Check the chained DateTimeParseException message to see exactly which part failed to parse.

Example fix

# before
restore_point_in_time: 15/01/2024 10:00 AM
# after
restore_point_in_time: 2024-01-15T10:00:00,000Z

String t = props.getProperty("restore_point_in_time");
if (t != null && !t.isEmpty())
    OffsetDateTime.parse(t.trim()); // throws DateTimeFormatException early if invalid

try { archiver = CommitLogArchiver.construct(); }
catch (RuntimeException e) {
    if ("Unable to parse restore target time".equals(e.getMessage()))
        log.error("Use ISO-8601 format, e.g. 2024-01-15T10:00:00,000Z", e);
    throw e;
}

When it happens

Trigger: getArchiverFromProperties() reads a non-empty restore_point_in_time value (e.g. '2024/01/15 10:00:00' or 'yesterday') and getRestorationPointInTimeInMicroseconds throws DateTimeParseException.

Common situations: Locale-specific date formats; human-readable values like 'yesterday'; missing timezone offset where one is required; typos such as single-digit months without the expected pattern.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• commitlog_directory must not be the same as any…
• local_system_data_file_directory must not be the same as…
• NANOSECONDS level precision is not supported.
• Unable to create directory:
• Unable to determine block size for commit log directory

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

Appendix: source

Thrown at src/java/org/apache/cassandra/db/commitlog/CommitLogArchiver.java:171

        {
            throw new RuntimeException("Unable to parse precision of value " + precisionPropertyValue, ex);
        }
        if (precision == TimeUnit.NANOSECONDS)
            throw new RuntimeException("NANOSECONDS level precision is not supported.");

        String targetTime = commitlogCommands.getProperty("restore_point_in_time");
        long restorePointInTime = Long.MAX_VALUE;
        try
        {
            if (!Strings.isNullOrEmpty(targetTime))
            {
                // get restorePointInTime in microseconds level by default as cassandra use this level's timestamp
                restorePointInTime = getRestorationPointInTimeInMicroseconds(targetTime);
            }
        }
        catch (DateTimeParseException e)
        {
            throw new RuntimeException("Unable to parse restore target time", e);
        }

        String snapshotPosition = commitlogCommands.getProperty("snapshot_commitlog_position");
        CommitLogPosition snapshotCommitLogPosition;
        try
        {

            snapshotCommitLogPosition = Strings.isNullOrEmpty(snapshotPosition)
                                        ? CommitLogPosition.NONE
                                        : CommitLogPosition.serializer.fromString(snapshotPosition);
        }
        catch (ParseException | NumberFormatException e)
        {
            throw new RuntimeException("Unable to parse snapshot commit log position", e);
        }

        return new CommitLogArchiver(archiveCommand,
                                     restoreCommand,

View on GitHub (pinned to 88fd0f6a0e)