[keshavdandeva]

b/577457377

Summary

On the REST path, BigQuery returns TIMESTAMP values as float64 seconds by default. That loses microseconds for dates far from 1970, and 9999-12-31 23:59:59.999999 UTC comes back as year 10000. The value is rounded by the server, so the driver can't fix it on the client.

Fix

• Connections now request useInt64Timestamp(true), which returns exact epoch microseconds. With EnableTimestampPicos=1 we still request ISO8601_STRING, because BigQuery rejects both together.
• The REST path now reads int64 TIMESTAMP values as epoch micros, as the Arrow path already does. This covers top-level, STRUCT/ARRAY and RANGE values.

Tests

• BigQueryConnectionTest: default connections request int64 timestamps.
• BigQueryJsonResultSetTest: int64 TIMESTAMP and RANGE<TIMESTAMP> values decode exactly.
• ITTimestampTimeZoneTest: adds 9999-12-31 23:59:59.999999 UTC to the existing getTimestamp / getString checks across 4 JVM zones. These checks fail without the fix (+10000-01-01) and pass with it.

[gemini-code-assist]

Code Review

This pull request implements support for lossless int64-encoded timestamps when picosecond precision is disabled. It configures DataFormatOptions to request int64 timestamps by default, preserves FieldValue wrappers for TIMESTAMP columns to identify these encoded values, and decodes them to epoch microseconds during type conversion and range formatting. The review feedback suggests improving the robustness of the range bound parsing in BigQueryTemporalUtility by wrapping the Long.valueOf conversions in a try-catch block to handle potential NumberFormatExceptions and throw a BigQueryJdbcException.