## TL;DR
Inference sees a value like 2026-01-05 and, if the file or API sample carries a midnight time or a format hint, may call it a timestamp. The column then lands as timestamp, the downstream partition defined on a date no longer lines up, and date equality filters silently miss. Stop inferring this column: declare it a date in the loader or model, cast existing data in a controlled rebuild, and check every downstream partition and filter that assumed a date.

```text
agent's schema inference picked timestamp instead of date, broke downstream partition
```

## Use this when
- A downstream partition or pruning error appears after a load or model was regenerated.
- The warehouse shows a column typed timestamp where the business concept is a calendar date.
- Filters comparing the column to a date return no rows, while a range over the day returns them.

## Not for this skill when
- The events genuinely have meaningful times of day. Model them as timestamps on purpose and fix the partition design instead.
- The breakage is a timezone shift on true timestamps. That is a different correction.

## Steps
1. Confirm the type change: compare the column type in the warehouse now against a previous table snapshot, an older model, or the documented schema. Note when the type flipped and what load change coincided. Verify: the inference change is tied to a specific load version
2. Inspect the raw source values for the column across several files or days, looking for midnight times, mixed formats, or a sample row that misleads inference. Note the misleading shape if present. Verify: you know why inference guessed timestamp
3. Declare the schema explicitly in the loader, the file reader config, or the staging model: this column is a date, parsed with a stated format. Note the declaration location so regeneration keeps it. Verify: the type no longer depends on the sample of the day
4. Rebuild the affected table or partition set with the date type, casting the existing timestamps by truncating, and verify no rows fall outside expected dates. Note row counts by date before and after. Verify: the corrected table matches the old counts per date
5. Find downstream models and queries that compare or partition on the column, align them to the date type, and rerun their tests. Note the partition filter returns rows again. Verify: downstream date logic works on the restored type

## Variant phrasings
### date column inferred as timestamp partition filter returns no rows
The symptom phrasing.
### schema inference date vs timestamp loader fix explicit schema
The explicit schema answer searched directly.

Compatibility: Any inference based loader or generated staging model feeding Snowflake, BigQuery, or another warehouse with distinct date and timestamp types. Partition definitions are warehouse specific; the type discipline is not.

## Why it happens
Date and timestamp look interchangeable in a sample and behave differently everywhere that matters: equality, grouping, partition membership, and joins to a calendar table. Inference optimises for parsing the sample in front of it, and a single row with a time component, often midnight from a system that stores dates as datetimes, tips the guess. Because every individual value still looks right after the load, the breakage surfaces downstream as empty partitions and silent filter misses rather than a load error anyone connects to a type.

## Edge cases / pitfalls
- Truncating timestamps to dates in a different timezone than the business date moves some rows across midnight. State the timezone of the truncation.
- Other inferred columns in the same load deserve the same audit. Inference rarely gets exactly one column wrong.
- Pin the whole schema for production loads, not just this column. A schema file in version control is the durable fix.
- Calendar or date dimension joins fail silently to nulls on a type mismatch in some warehouses. Check join hit rates after the fix.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GDnR4I3vNEKRpjPwPnMIQw