apache/seatunnel · warning

The time column {} type time({}) is out of range, which exce

Error message

The time column {} type time({}) is out of range, which exceeds the maximum scale of {}, it will be converted to time({})

What it means

A log warning in DmdbTypeConverter.reconvert for TIME columns: the fractional-second scale exceeds MAX_TIME_SCALE, so the converter clamps it to the maximum. The DM TIME column will have reduced sub-second precision. Note the log also prints MAX_SCALE in the 'maximum scale of {}' slot, which is a cosmetic inconsistency.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/dm/DmdbTypeConverter.java:460

                    builder.columnType(
                            String.format("%s(%s)", DM_VARBINARY, column.getColumnLength()));
                    builder.dataType(DM_VARBINARY);
                } else {
                    builder.columnType(DM_LONGVARBINARY);
                    builder.dataType(DM_LONGVARBINARY);
                }
                break;
            case DATE:
                builder.columnType(DM_DATE);
                builder.dataType(DM_DATE);
                break;
            case TIME:
                builder.dataType(DM_TIME);
                if (column.getScale() != null && column.getScale() > 0) {
                    Integer timeScale = column.getScale();
                    if (timeScale > MAX_TIME_SCALE) {
                        timeScale = MAX_TIME_SCALE;
                        log.warn(
                                "The time column {} type time({}) is out of range, "
                                        + "which exceeds the maximum scale of {}, "
                                        + "it will be converted to time({})",
                                column.getName(),
                                column.getScale(),
                                MAX_SCALE,
                                timeScale);
                    }
                    builder.columnType(String.format("%s(%s)", DM_TIME, timeScale));
                    builder.scale(timeScale);
                } else {
                    builder.columnType(DM_TIME);
                }
                break;
            case TIMESTAMP:
                builder.dataType(DM_TIMESTAMP);
                if (column.getScale() != null && column.getScale() > 0) {
                    Integer timestampScale = column.getScale();

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Reduce the source time column scale to Dameng's MAX_TIME_SCALE
  2. Accept the clamped time(x) precision if sub-second truncation is acceptable
  3. Pre-create the DM column with the needed precision and bypass automatic conversion
  4. Round timestamps in a transform before the sink to match target precision

Example fix

// before
TIME(9)
// after
TIME(3) -- clamped to MAX_TIME_SCALE
Defensive patterns

Strategy: validation

Validate before calling

if (column.getScale() != null && column.getScale() > MAX_TIME_SCALE) {
    // reduce source TIME precision before sync
}

Prevention

When it happens

Trigger: reconvert() on a LocalTimeType/time column with scale != null && scale > 0 && scale > MAX_TIME_SCALE (e.g. TIME(9) from a source supporting nanosecond precision).

Common situations: Syncing time columns from sources with nanosecond precision (e.g. MySQL TIME(6), Postgres TIME(6)) into Dameng which supports fewer fractional digits; users noticing truncated precision.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/8af1ae511b18ade1. Report an issue: GitHub.