[kvlonge]

Why

A Snowflake source with an enforced contract that declares a precision on a time column, such as TIME(3) or TIME(9), failed planning with S404 although the warehouse column matched. Metadata reads (INFORMATION_SCHEMA and SHOW COLUMNS alike) report time and timestamp types without their fractional-seconds precision, so the declared TIME(3) was compared with a bare TIME. TIMESTAMP_TZ(p) failed the same way; TIMESTAMP_NTZ and TIMESTAMP_LTZ already compared equal because normalization drops their precision.

Changes

• Snowflake type equality treats an unstated time or timestamp precision as matching any precision of the same type. Two stated precisions must still agree, and different temporal types (TIME against TIMESTAMP_NTZ, TIMESTAMP_TZ against TIMESTAMP_LTZ) still differ. Other dialects keep exact comparison.
• The rule lives in one native helper used by every declared-against-warehouse comparison: source contracts, schema-change findings and contract comparison.
• Reading the precision from metadata instead was considered. Observed type strings are stored and compared across runs, so adding a precision to them would change a stored format in place and report one-time false schema changes for existing time columns. Comparing up to an unknown precision fixes the false mismatch without that migration.

Verification

• Unit: the comparison over TIME, TIMESTAMP_TZ/LTZ/NTZ, stated and unstated precisions, other dialects and text lengths.
• Integration: an offline Snowflake plan whose source columns come through the SHOW COLUMNS parsing path, with enforced TIME(3), TIME(9), TIMESTAMP_TZ(9), TIMESTAMP_LTZ(3) and TIMESTAMP_NTZ(6) contracts passing and real type mismatches still failing.
• make test and make check-ci.