A Snowflake Parquet load succeeds, then dates show as impossible years

The load job reports success, but a timestamp column renders as “Invalid date” or an absurdly distant year. A Stack Overflow case traced one such symptom to inconsistent source values and epoch-unit interpretation. A second Parquet-to-Snowflake question describes a writer-dependent timestamp shift. Neither means every bad date has the same cause.

Inspect the file before changing SQL

Compare the physical Parquet type, logical timestamp annotation and sample raw values for both good and bad rows. Determine whether integers represent seconds, milliseconds, microseconds or nanoseconds. Check whether the source contains timezone information and whether the target is TIMESTAMP_NTZ, LTZ or TZ. A conversion that succeeds syntactically can still express the wrong instant.

Reproduce one value explicitly

Snowflake's timestamp conversion documentation explains differences when values arrive as numbers, strings or values inside a variant. Run one known input through explicit conversions at the suspected scales and compare it with the source system's intended instant. Then inspect the Parquet file-format settings and the loading path. USE_LOGICAL_TYPE can affect Parquet interpretation, but it should be chosen from the file schema and tested, not used as a universal repair switch.

Fix the pipeline contract

Standardize the writer's timestamp type and unit, add a load-time range check, and quarantine values outside the business-valid period. Keep an example file and expected output in the pipeline's regression check. An accepted COPY is a transport result; it is not a data-quality certificate.

Adovo’s view

Time is a contract between systems. If its unit and timezone live only in the writer's assumptions, the warehouse will eventually tell a convincing lie. Put that contract in the schema and prove it with a known instant.