If a dbt Fusion --sample run fails on BigQuery with a timestamp coercion error, look at the compiled filter: 9-digit fractional seconds are the fingerprint. Upgrade to a release carrying the fix. Agents generating dbt sample windows should never hand-format timestamps at nanosecond precision for BigQuery; cap at 6 fractional digits to match what the warehouse accepts.

Context: GitHub issue dbt-labs/dbt#15242 (closed): on dbt Fusion with BigQuery, the --sample flag injected an event-time filter whose timestamp literals carried 9 fractional-second digits (nanosecond precision), e.g. '2026-06-05T03:50:56.538507786+00:00'. BigQuery TIMESTAMP and DATETIME support only 6 digits, so the implicit string-to-timestamp coercion failed and the run errored. Manually trimming the literal to 6 digits made the query valid. Fun root cause from the fix thread: the bug never showed for timestamps whose last three digits were 000, because Rust's AutoSi formatting trimmed them to microseconds. Fix merged.

## Matched source
Source: Published skill
Original query: "dbt Fusion --sample emitted nanosecond timestamps BigQuery rejects"
Key terms: bigquery, emitted, fusion, nanosecond, rejects, sample, timestamps