apache/seatunnel · warning

The scale of time type is larger than {}, it will be truncat

Error message

The scale of time type is larger than {}, it will be truncated to {}

What it means

While converting a Postgres TIME or TIME WITH TIME ZONE column (PG_TIME/PG_TIME_TZ) to a SeaTunnel type, a fractional-second scale above MAX_TIME_SCALE cannot be represented, so the converter logs this warning and truncates the scale to MAX_TIME_SCALE instead of failing.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/internal/dialect/psql/PostgresTypeConverter.java:258

                builder.sourceType(pgDataType);
                break;
            case PG_CHAR_ARRAY:
            case PG_VARCHAR_ARRAY:
            case PG_TEXT_ARRAY:
                builder.dataType(ArrayType.STRING_ARRAY_TYPE);
                break;
            case PG_BYTEA:
                builder.dataType(PrimitiveByteArrayType.INSTANCE);
                break;
            case PG_DATE:
                builder.dataType(LocalTimeType.LOCAL_DATE_TYPE);
                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());
                }

View on GitHub (pinned to cf67b549a7)

Solutions

1. Cast the column in your SQL/catalog query to a smaller scale, e.g. CAST(t AS TIME(3)).
2. Accept the truncation: verify your data does not need the dropped sub-second digits.
3. Set the column's scale explicitly in the source config/catalog so it stays within MAX_TIME_SCALE.
4. If microsecond precision is essential, use a string or timestamp representation instead.

Example fix

// before: SELECT event_time FROM pg_table; -- TIME(6)
// after
SELECT CAST(event_time AS TIME(3)) AS event_time FROM pg_table;

Integer scale = typeDefine.getScale();
if (scale != null && scale > maxTimeScale) {
    // cast in the source query instead: CAST(col AS TIME(3))
}

boolean fitsPostgresTimeScale(TypeDefine t) {
    return t.getScale() == null || t.getScale() <= 3;
}

When it happens

Trigger: PostgresTypeConverter.convert() on a typeDefine for TIME/TIMETZ whose scale is greater than MAX_TIME_SCALE (e.g. TIME(6) microsecond precision from Postgres).

Common situations: Reading Postgres tables with high-precision TIME columns; catalog readers reporting fractional precision larger than the engine's supported time scale.

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 exce
• The scale of timestamp type is larger than {}, it will be tr
• The decimal column {} type decimal({},{}) is out of range, w
• The decimal column {} type decimal({},{}) is out of range, w
• The timestamp column {} type timestamp({}) is out of range,

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