You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit bc84520
Browse filesBrowse the repository at this point in the historyBrowse files
fix(bigquery-jdbc): request int64 timestamps so the REST path is lossless (#14890)
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.
0 commit comments