diff --git a/get-started/setup-lightdash/connect-project.mdx b/get-started/setup-lightdash/connect-project.mdx
index 5f6723b0..9b486947 100644
--- a/get-started/setup-lightdash/connect-project.mdx
+++ b/get-started/setup-lightdash/connect-project.mdx
@@ -187,6 +187,19 @@ This controls what day is the start of the week in Lightdash. `Auto` sets it to
 
 Here you can specify an execution project to bill for query execution, instead of using the project where your dbt resources are materialized. If you leave this blank, all costs get applied to the project from the top of the connection details.
 
+
+##### Data timezone
+
+The timezone Lightdash uses to interpret naive `DATETIME` values (columns without an explicit offset) coming back from BigQuery. When set, Lightdash passes `time_zone` as a connection property on every BigQuery job it runs — the per-job equivalent of a session timezone — so naive values are read in the configured zone rather than UTC, and day-truncation buckets line up with local wall-clock values.
+
+- **Where it applies:** every query the project runs, including scheduled deliveries, ad-hoc queries in the explore view, and the connection form's Data timezone preview.
+- **Aware `TIMESTAMP` columns are unaffected.** They already carry an explicit instant, so Data timezone does not change their stored values — only the [project timezone](/guides/developer/timezones#configure-your-project-timezone) controls how they're displayed and grouped.
+- **Leave it unset to preserve prior behavior.** No `time_zone` job property is sent and naive values are read as UTC.
+
+For example, if your warehouse logs naive `DATETIME` values in Tokyo local time, set **Data timezone** to `Asia/Tokyo`. The preview on the connection form will confirm the interpretation (e.g. "read as Asia/Tokyo") before you save.
+
+See the [timezones guide](/guides/developer/timezones#configure-your-connection) for a deeper walkthrough of when to change this setting.
+
 ***