[keshavdandeva]

b/570670164

Summary

RANGE values were formatted inconsistently depending on element type and read path:

• REST RANGE<TIMESTAMP> returned raw epoch seconds: [1767225600.000000, 1798761599.000000)
• REST RANGE<DATETIME> used a T separator: [2026-01-01T00:00:00, ...)
• Arrow formatted both differently from REST
• Arrow STRUCT<RANGE> returned a raw map: {"start":...,"end":...}

Fix

Added a single BigQueryTemporalUtility.formatRange used by all REST and Arrow read paths (top-level, ARRAY, STRUCT). Each bound now reads exactly like getString on its element type:

Element	Output
DATE	[2026-01-01, 2026-12-31)
DATETIME	[2026-01-01 00:00:00.000000, 2026-12-31 23:59:59.000000)
TIMESTAMP (UTC)	[2026-01-01 00:00:00.000000, 2026-12-31 23:59:59.000000)

UNBOUNDED is kept for open bounds. EnableTimestampPicos now only controls TIMESTAMP fraction digits (6 vs 12) instead of gating formatting altogether.

Behaviour change

REST callers parsing the old epoch / T-separated strings will see the new format.

Testing

• Unit: formatter coverage for REST and Arrow inputs; RANGE inside STRUCT and ARRAY for both paths.
• IT: updated testRangeDataTypeWithJsonResultSet; added testRangeBoundsFormatIdenticallyOnRestAndArrow (REST vs. Arrow parity).

[gemini-code-assist]

Code Review

This pull request refactors the formatting of RANGE data types across the BigQuery JDBC driver by consolidating duplicate formatting logic from various result set and struct classes into a centralized utility method, BigQueryTemporalUtility.formatRange. Feedback on these changes includes a recommendation to check if a FieldValue is null before retrieving its range value to prevent potential exceptions, as well as a suggestion to remove redundant case normalization when parsing range element types.

[Neenu1995]

LGTM, but there may be some dead code to clean up in TypeRegistry.