fix: Fix BigQuery timestamp literal format in SQL unparsing

[sgrebnov]

Which issue does this PR close?

The default Dialect::timestamp_with_tz_to_string uses dt.to_string() which produces timestamps with a space before the TimeZone offset:

2016-08-06 20:05:00 +00:00 <- invalid for BigQuery:
invalid timestamp: '2016-08-06 20:05:00 +00:00'; while executing the filter on column 'startTime' (query) (sqlstate: [0, 0, 0, 0, 0], vendor_code: -2147483648)

BigQuery rejects this format. Per the BigQuery timestamp docs, the offset must be attached directly to the time:

2016-08-06 20:05:00+00:00 <- valid

This causes filter pushdown to fail when unparsing timestamp predicates for BigQuery.

Changes

Override timestamp_with_tz_to_string in BigQueryDialect using chrono's %:z format specifier, which produces the offset without a leading space.

Before (default dt.to_string()):

CAST('2016-08-06 20:05:00 +00:00' AS TIMESTAMP)  -- BigQuery error

After (%:z format):

CAST('2016-08-06 20:05:00+00:00' AS TIMESTAMP)  -- valid BigQuery timestamp

Similar to DuckDB recent fix: apache#17653

[Copilot]

Pull request overview

Fixes BigQuery SQL unparsing for TIMESTAMP values with time zone offsets by ensuring the UTC offset is formatted without a leading space, preventing BigQuery “invalid timestamp” errors during filter pushdown.

Changes:

• Override Dialect::timestamp_with_tz_to_string in BigQueryDialect.
• Format timestamp-with-TZ strings using chrono’s %:z to attach the offset directly to the time, with precision based on TimeUnit.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sgrebnov]

Upstream PR: apache#21103