Changing from DateType to TimestampType is allowed, but be…

Error message

Changing from DateType to TimestampType is allowed, but be wary that they sort differently for pre-unix-epoch timestamps (negative timestamp values) and thus this change will corrupt your data if you have such negative timestamp. So unless you know that you don't have *any* pre-unix-epoch timestamp you should change back to DateType

What it means

TimestampType.isCompatibleWith allows changing a column from DateType to TimestampType since encodings are byte-compatible, but sort order differs for negative (pre-1970) values, so on-disk sorted data would be corrupted if such values exist. Cassandra logs this warning and permits the change so operators can correct a prior accidental switch.

Solutions

Audit the column for pre-unix-epoch values (negative timestamps) before altering
If pre-1970 values exist, do not alter; instead rewrite data into a new timestamp column
If no negative values exist, proceed with the ALTER; the warning can be ignored
Document the type change so future restores do not ping-pong between the two types

Example fix

// before: blind alter
ALTER TABLE events ALTER at TYPE timestamp;
// after: pre-check for pre-epoch values
SELECT at FROM events WHERE at < toTimestamp('1970-01-01') LIMIT 1 ALLOW FILTERING; // empty -> safe

Defensive patterns

Strategy: validation

Validate before calling

// pre-check before DateType -> TimestampType alter
ResultSet rs = session.execute("SELECT pk FROM t WHERE at < '1970-01-01' ALLOW FILTERING");
if (!rs.isEmpty()) throw new IllegalStateException("Pre-epoch values exist; altering will corrupt sort order");

Prevention

Audit pre-1970 data before comparator type changes
Keep one canonical temporal type per dataset
Capture schema snapshots before ALTERs
Rehearse migrations on restored test data

When it happens

Trigger: ALTER TABLE ... ALTER <column> TYPE timestamp on a column whose comparator is DateType, typically to undo an earlier accidental DateType migration, via CQL ALTER or schema-restore of old metadata.

Common situations: Correcting a legacy schema; restoring schema snapshots from very old clusters where DateType was default for date-like columns; blind schema migrations without auditing pre-1970 data.

Understand the failure class

Background: "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires — this error's family across 65 libraries.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/db/marshal/TimestampType.java:144

    {
        return date != null ? TimestampSerializer.getJsonDateFormatter().format(date.toInstant()) : "";
    }

    @Override
    public String toJSONString(ByteBuffer buffer, ProtocolVersion protocolVersion)
    {
        return '"' + toString(TimestampSerializer.instance.deserialize(buffer)) + '"';
    }

    @Override
    public boolean isCompatibleWith(AbstractType<?> previous)
    {
        if (super.isCompatibleWith(previous))
            return true;

        if (previous instanceof DateType)
        {
            logger.warn("Changing from DateType to TimestampType is allowed, but be wary that they sort differently for pre-unix-epoch timestamps "
                      + "(negative timestamp values) and thus this change will corrupt your data if you have such negative timestamp. So unless you "
                      + "know that you don't have *any* pre-unix-epoch timestamp you should change back to DateType");
            return true;
        }

        return false;
    }

    @Override
    public boolean isValueCompatibleWithInternal(AbstractType<?> otherType)
    {
        return this == otherType || otherType == DateType.instance || otherType == LongType.instance;
    }

    public CQL3Type asCQL3Type()
    {
        return CQL3Type.Native.TIMESTAMP;
    }

View on GitHub (pinned to 88fd0f6a0e)