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
- Reduce the source time column scale to Dameng's MAX_TIME_SCALE
- Accept the clamped time(x) precision if sub-second truncation is acceptable
- Pre-create the DM column with the needed precision and bypass automatic conversion
- 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
- Match time fractional precision between source and Dameng in schema design
- Treat nanosecond-precision time columns as lossy when targeting Dameng
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
- The timestamp column {} type timestamp({}) is out of range,
- The timestamp_tz column {} type datetime_tz({}) is out of ra
- The time column {} type time({}) is out of range, which exce
- DATABASE_NOT_EXISTED
- Failed listing table in catalog %s
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/8af1ae511b18ade1.
Report an issue: GitHub.