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 }}
This repository was archived by the owner on Mar 6, 2026. It is now read-only.
This can cause unexpected floating point issues when rounding timestamps in SQL, such as with the TIMESTAMP_TRUNC(COL_TIMESTAMP, MILLISECOND) function.
Wherever tabledata.list, jobs.query, or jobs.getQueryResults are called, set the formatOptions.useInt64Timestamp option to True.
Wherever timestamps in rows API responses are handled, update it to use integer math to extract microseconds and seconds.
Add system tests to verify that timestamps rounded to every digit of supported precision (e.g. 9, 9.9, 9.99, ..., 9.999999) are returned exactly as set in the table/query.
Describe alternatives you've considered
N/A
Additional context
Precision issues for the other direction (to BigQuery) for similar floating-point reasons: #392
Is your feature request related to a problem? Please describe.
When fetching timestamp values, the tabledata.list and jobs.getQueryResults APIs return a floating point value by default.
This can cause unexpected floating point issues when rounding timestamps in SQL, such as with the
TIMESTAMP_TRUNC(COL_TIMESTAMP, MILLISECOND)function.Describe the solution you'd like
The backend API adds a
formatOptions.useInt64Timestampoption.tabledata.list,jobs.query, orjobs.getQueryResultsare called, set theformatOptions.useInt64Timestampoption toTrue.Describe alternatives you've considered
N/A
Additional context
Precision issues for the other direction (to BigQuery) for similar floating-point reasons: #392