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

  1. Cast the column in the source query, e.g. CAST(ts AS TIMESTAMP(3)).
  2. Verify the truncated fractional precision meets your application's needs.
  3. Declare the column scale explicitly in the catalog to stay within MAX_TIMESTAMP_SCALE.
  4. 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

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


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