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.useInt64Timestamp option.
- 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