apache/seatunnel · warning
The timestamp column
Error message
The timestamp column {} type timestamp({}) is out of range, which exceeds the maximum scale of {}, it will be converted to timestamp({}) What it means
Warning from XuguTypeConverter.reconvert for TIMESTAMP columns whose scale exceeds XuGu's MAX_TIMESTAMP_SCALE. The converter lowers timestampScale to the maximum and logs instead of failing, so fractional-second digits beyond the maximum are lost.
Solutions
- Cap the source timestamp precision to XuGu's maximum (e.g. CAST(ts_col AS TIMESTAMP(3))).
- Accept the clamp (warning only) and confirm downstream consumers tolerate truncated fractions.
- Define the target XuGu column explicitly with an in-range scale.
Example fix
// before: timestamp(9) // after SQL: CAST(ts_col AS TIMESTAMP(6)) AS ts_col
Defensive patterns
Strategy: validation
Validate before calling
if (col.getSqlType() == SqlType.TIMESTAMP && col.getColumnScale() > MAX_TIMESTAMP_SCALE) {
col = col.copy().setColumnScale(MAX_TIMESTAMP_SCALE).build();
} Type guard
boolean withinTimestampScale(ColumnType c) { return c.getScale() == null || c.getScale() <= MAX_TIMESTAMP_SCALE; } Prevention
- Cap timestamp precision at the source (e.g. TIMESTAMP(3) or (6))
- Compare source dialect max scale with XuGu's before table creation
- Grep logs for 'is out of range' after catalog sync
When it happens
Trigger: Writing a SeaTunnel TIMESTAMP column with scale > MAX_TIMESTAMP_SCALE into XuGu via catalog sink, e.g. timestamp(9) from a nanosecond-precision source.
Common situations: Replicating MySQL DATETIME(6)/TIMESTAMP(6) or PostgreSQL timestamptz(6) tables into XuGu; schema sync carrying higher precision than the target supports.
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 time column type time( ) is out of range, which exceeds…
- The timestamp_tz column
- COMMON-17
- COMMON-19
- COMMON-17
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/9cca98ed1e20ed82.
Report an issue: GitHub.
Appendix: source
Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/xugu/XuguTypeConverter.java:371
column.getName(),
column.getScale(),
MAX_SCALE,
timeScale);
}
builder.columnType(String.format("%s(%s)", XUGU_TIME, timeScale));
builder.scale(timeScale);
} else {
builder.columnType(XUGU_TIME);
}
break;
case TIMESTAMP:
if (column.getScale() == null || column.getScale() <= 0) {
builder.columnType(XUGU_TIMESTAMP);
} else {
int timestampScale = column.getScale();
if (column.getScale() > MAX_TIMESTAMP_SCALE) {
timestampScale = MAX_TIMESTAMP_SCALE;
log.warn(
"The timestamp column {} type timestamp({}) is out of range, "
+ "which exceeds the maximum scale of {}, "
+ "it will be converted to timestamp({})",
column.getName(),
column.getScale(),
MAX_TIMESTAMP_SCALE,
timestampScale);
}
builder.columnType(String.format("TIMESTAMP(%s)", timestampScale));
builder.scale(timestampScale);
}
builder.dataType(XUGU_TIMESTAMP);
break;
case TIMESTAMP_TZ:
if (column.getScale() == null || column.getScale() <= 0) {
builder.columnType(XUGU_TIMESTAMP_WITH_TIME_ZONE);
} else {
int timestampTzScale = column.getScale();View on GitHub (pinned to cf67b549a7)