[keshavdandeva]

b/570670063

Summary

Reading a TIMESTAMP within 1 ms of the Unix epoch (excluding exactly 0) over the REST API threw BigQueryConversionException from getString, getTimestamp and getObject.

Root cause

The REST API sends these values in scientific notation (1.0E-6, -1.0E-4). BigQueryTemporalUtility.boxTimestamp used '-' to tell epoch decimals from ISO strings, so a negative exponent sent the value down the ISO path, where Timestamp.valueOf threw.

Fix

Treat a value as an epoch decimal when it has no ':'. Every ISO/civil timestamp has one and no epoch decimal does. This is the same check formatTimestampValue already uses.

This also fixes TIMESTAMP values inside STRUCT/ARRAY on the REST path, which go through the same method. Arrow was not affected: it sends TIMESTAMP as Long micros.

Tests

• BigQueryTemporalUtilityTest#testBoxTimestamp: added 1.0E-6, 9.99E-4, -1.0E-6, -1.0E-4.
• ITTimestampTimeZoneTest: added ±1 µs columns to the shared query and asserted them in testGetString_returnsUtcDigits and testGetTimestampAndGetObject_returnMoment, across 4 JVM zones.

[gemini-code-assist]

Code Review

This pull request updates BigQueryTemporalUtility.boxTimestamp to correctly parse epoch decimals in scientific notation (e.g., "1.0E-6"), which are used by the JSON/REST API for timestamps close to the epoch. It also adds comprehensive unit and integration tests to verify this behavior. The review feedback highlights a potential performance issue where DATE strings (which lack colons) will trigger a caught NumberFormatException in a hot path, and provides a code suggestion to optimize this check by ensuring hyphens are only allowed at the start or when preceded by 'E' or 'e'.