apache/seatunnel · warning
The scale of timestamp type is larger than {}, it will be tr
Error message
The scale of timestamp type is larger than {}, it will be truncated to {} What it means
While converting a Postgres TIMESTAMP column (PG_TIMESTAMP) to a SeaTunnel type, a scale above MAX_TIMESTAMP_SCALE cannot be represented, so the converter logs this warning and truncates the scale to MAX_TIMESTAMP_SCALE rather than failing. Extra fractional-second digits are dropped.
Source
Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/psql/PostgresTypeConverter.java:270
break;
case PG_TIME:
case PG_TIME_TZ:
builder.dataType(LocalTimeType.LOCAL_TIME_TYPE);
if (typeDefine.getScale() != null && typeDefine.getScale() > MAX_TIME_SCALE) {
builder.scale(MAX_TIME_SCALE);
log.warn(
"The scale of time type is larger than {}, it will be truncated to {}",
MAX_TIME_SCALE,
MAX_TIME_SCALE);
} else {
builder.scale(typeDefine.getScale());
}
break;
case PG_TIMESTAMP:
builder.dataType(LocalTimeType.LOCAL_DATE_TIME_TYPE);
if (typeDefine.getScale() != null && typeDefine.getScale() > MAX_TIMESTAMP_SCALE) {
builder.scale(MAX_TIMESTAMP_SCALE);
log.warn(
"The scale of timestamp type is larger than {}, it will be truncated to {}",
MAX_TIMESTAMP_SCALE,
MAX_TIMESTAMP_SCALE);
} else {
builder.scale(typeDefine.getScale());
}
break;
case PG_TIMESTAMP_TZ:
// timestamptz -> TIMESTAMP_TZ
builder.dataType(LocalTimeType.OFFSET_DATE_TIME_TYPE);
if (typeDefine.getScale() != null && typeDefine.getScale() > MAX_TIMESTAMP_SCALE) {
builder.scale(MAX_TIMESTAMP_SCALE);
} else {
builder.scale(typeDefine.getScale());
}
break;
default:
if (typeDefine.getSqlType() == Types.OTHER) {View on GitHub (pinned to cf67b549a7)
Solutions
- Cast the column in the source query, e.g. CAST(ts AS TIMESTAMP(3)).
- Verify the truncated fractional precision meets your application's needs.
- Declare the column scale explicitly in the catalog to stay within MAX_TIMESTAMP_SCALE.
- Store the value as a string/epoch-nanos column if full precision must be preserved.
Example fix
// before: SELECT ts FROM pg_table; -- TIMESTAMP(6) // after SELECT CAST(ts AS TIMESTAMP(3)) AS ts FROM pg_table;
Defensive patterns
Strategy: validation
Validate before calling
Integer scale = typeDefine.getScale();
if (scale != null && scale > maxTimestampScale) {
// cast in the source query instead: CAST(col AS TIMESTAMP(3))
} Type guard
boolean fitsPostgresTimestampScale(TypeDefine t) {
return t.getScale() == null || t.getScale() <= 3;
} Prevention
- SELECT CAST(ts AS TIMESTAMP(3)) in source queries
- Match engine timestamp scale limits in schema design
- Store full-precision timestamps as epoch values when needed
When it happens
Trigger: PostgresTypeConverter.convert() on a typeDefine for TIMESTAMP whose scale exceeds MAX_TIMESTAMP_SCALE (e.g. TIMESTAMP(6) microseconds from Postgres tables).
Common situations: Reading Postgres TIMESTAMP(6)/TIMESTAMP(p) columns where p exceeds the engine's timestamp scale; schema inference passing through the full 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 scale of time type is larger than {}, it will be truncat
- The timestamp column {} type timestamp({}) is out of range,
- The timestamp_tz column {} type timestamp({}) is out of rang
- The decimal column {} type decimal({},{}) is out of range, w
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/7f1c83bcbc5aac48.
Report an issue: GitHub.