fix(bigquery-jdbc): preserve Timestamp instant in PreparedStatement and CallableStatement Calendar overloads

[keshavdandeva]

b/565785264

Summary

Fixes an issue where passing a Calendar to PreparedStatement.setTimestamp or CallableStatement.setTimestamp/getTimestamp corrupted the underlying UTC instant by shifting it by JVM_offset - Calendar_offset (or 2 * (JVM_offset - Calendar_offset) on a CallableStatement setter-to-getter round trip).

Root Cause

A java.sql.Timestamp already represents an absolute UTC epoch instant (milliseconds + nanos), and BigQuery's TIMESTAMP type is a timezone-aware absolute instant. Previously, the Calendar overloads called BigQueryTemporalUtility.convertTimestampWithCalendar(ts, cal), which extracted the JVM-local wall-clock fields (ts.toLocalDateTime()) and re-anchored them in cal.getTimeZone(), shifting the epoch instant whenever the Calendar timezone differed from the JVM default timezone.

Changes

• BigQueryPreparedStatement: Delegate setTimestamp(int, Timestamp, Calendar) directly to setTimestamp(int, Timestamp).
• BigQueryCallableStatement: Delegate getTimestamp(int, Calendar), getTimestamp(String, Calendar), and setTimestamp(String, Timestamp, Calendar) directly to their non-Calendar counterparts.
• BigQueryTemporalUtility: Remove unused convertTimestampWithCalendar(Timestamp, Calendar) helper.
• Tests: Update unit and integration tests (BigQueryPreparedStatementSettersTest, BigQueryCallableStatementTest, BigQueryTemporalUtilityTest, ITCallableStatementTest) to verify Timestamp preservation across distinct JVM (America/New_York) and Calendar (Asia/Tokyo) timezones.

[gemini-code-assist]

Code Review

This pull request simplifies timestamp handling in BigQueryCallableStatement and BigQueryPreparedStatement by removing the BigQueryTemporalUtility.convertTimestampWithCalendar utility and delegating Calendar-based timestamp getters and setters to their non-Calendar overloads. However, feedback highlights that ignoring the Calendar parameter entirely may cause issues with timezone-naive DATETIME values, which should be interpreted using the provided Calendar's timezone. Additionally, several test updates modify the JVM-wide default timezone (TimeZone.setDefault), which can introduce flakiness and race conditions during parallel test execution; it is recommended to dynamically select a test timezone instead.