add event_time page

[mirnawong1]

this pr adds a new page for the event_time config for models, sources, snapshots, and sources.

also adds to the advanced ci and links from other pages.

this PR #6384 will merge into this pr.

docs notion

some. outstanding items:

• should we change the source page config as it only says 'enabled' is supported?

---

🚀 Deployment available! Here are the direct links to the updated files:

• https://docs-getdbt-com-git-add-event-time-dbt-labs.vercel.app/docs/build/incremental-microbatch
• https://docs-getdbt-com-git-add-event-time-dbt-labs.vercel.app/docs/dbt-versions/release-notes
• https://docs-getdbt-com-git-add-event-time-dbt-labs.vercel.app/docs/deploy/advanced-ci
• https://docs-getdbt-com-git-add-event-time-dbt-labs.vercel.app/reference/resource-configs/event-time

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
docs-getdbt-com	✅ Ready (Inspect)	Visit Preview	Nov 11, 2024 4:54pm

[joellabes]

This looks great! A few suggested tweaks and clarifications but overall :chef_kiss:

[joellabes]

Suggested change

	- Compare data in CI versus production for overlapping times only, reducing false discrepancies.
	- Compare data in CI against production for only the overlapping times, avoiding false positives and returning results faster.

[nataliefiann]

Hiya @mirnawong1

I've approved this one for you and left some suggestions and non-blockers.

Kind Regards
Natalie

[graciegoheen]

I think both of these bullets have the same benefit of "using only the overlapping timeframe, which avoids incorrect row-count changes and returns results faster"

I would distinguish the 2 scenarios as:

• scenarios where your CI job only builds a subset of data
• scenarios where your CI job contains fresher data than production

Rather than nesting the second scenario within the first - lmk if that makes sense!

[mirnawong1]

changed it to this;

It's common for CI jobs to only build a subset of data (for example only the last 7 days of data).

When an event_time column is specified on your model, compare changes can optimize comparisons by using only the overlapping timeframe (meaning the timeframe exists in both the CI and production environment), helping you avoid incorrect row-count changes to return results faster.

This is useful in scenarios like:

• Subset of data in CI — When CI builds only a subset of data (like the most recent 7 days), compare changes might interpret the excluded data as "deleted rows." Configuring event_time allows you to avoid this issue by limiting comparisons to the overlapping timeframe, preventing false alerts about data deletions that are just filtered out in CI.
• Fresher data in CI than in production — When your CI job includes fresher data than production, compare changes might flag the additional rows as "new" data, even though they’re just fresher data in CI. With event_time configured, the comparison only includes the shared timeframe and correctly reflects actual changes in the data.