[jdbc-v2] setObject(ZonedDateTime) outside 1677-2262 silently stores a wrong DateTime64 value #3292

Description

JDBC V2 sends a ZonedDateTime (also OffsetDateTime and Instant) as fromUnixTimestamp64Nano(<epoch nanos>). This only fits in Int64 for 1677-09-21 00:12:43.145224192 to 2262-04-11 23:47:16.854775807 UTC. Outside that range the driver stores a wrong value without an error, or the server rejects the query.

The DateTime64 docs say the range is 0000-01-01 to 9999-12-31 for precisions up to 7. The 1677-2262 range applies only to precision 9. The driver applies it to every precision.

Steps to reproduce

1. Create a DateTime64(7, 'UTC') column.
2. Insert a ZonedDateTime with PreparedStatement.setObject().
3. Read it back with toString(dt).

Error Log or Exception StackTrace

For 3000-01-01 00:00:00Z:

java.sql.SQLException: Code: 43. DB::Exception: The first argument for function fromUnixTimestamp64Nano must be integer: In scope fromUnixTimestamp64Nano(32503680000000000000.): While executing WaitForAsyncInsert. (ILLEGAL_TYPE_OF_ARGUMENT) (version 26.8.34.13 (official build))  (queryId= cafe2b13-6035-4ad8-ad9d-a5e8463c0a56)
	at com.clickhouse.jdbc.internal.ExceptionUtils.toSqlState(ExceptionUtils.java:68)
	at com.clickhouse.jdbc.internal.ExceptionUtils.toSqlState(ExceptionUtils.java:41)
	at com.clickhouse.jdbc.StatementImpl.executeUpdateImpl(StatementImpl.java:416)
	at com.clickhouse.jdbc.PreparedStatementImpl.executeUpdate(PreparedStatementImpl.java:156)
Caused by: com.clickhouse.client.api.ServerException: Code: 43. DB::Exception: The first argument for function fromUnixTimestamp64Nano must be integer: In scope fromUnixTimestamp64Nano(32503680000000000000.): While executing WaitForAsyncInsert. (ILLEGAL_TYPE_OF_ARGUMENT) (version 26.8.34.13 (official build))
	at com.clickhouse.client.api.internal.HttpAPIClientHelper.readClickHouseError(HttpAPIClientHelper.java:534)
	at com.clickhouse.client.api.internal.HttpAPIClientHelper.readError(HttpAPIClientHelper.java:426)
	at com.clickhouse.client.api.internal.HttpAPIClientHelper.doExecuteRequest(HttpAPIClientHelper.java:833)
	at com.clickhouse.client.api.Client.query(Client.java:2081)
	at com.clickhouse.jdbc.StatementImpl.executeUpdateImpl(StatementImpl.java:409)

Expected Behaviour

The value is stored correctly, or the driver throws a clear error. The server handles these values correctly, and so does setObject(index, "1500-06-01 00:00:00") with a String.

Suspected cause, in DataTypeUtils.toUnixTimestampString(long seconds, int nanos): below the range TimeUnit.SECONDS.toNanos(seconds) saturates at Long.MIN_VALUE, and above it the BigInteger value does not fit in Int64.

Code Example

com.clickhouse.jdbc.Driver.load();
try (Connection c = DriverManager.getConnection("jdbc:clickhouse://localhost:8123/default", "default", "");
        Statement s = c.createStatement()) {
    s.execute("CREATE TABLE t (dt DateTime64(7, 'UTC')) ENGINE = Memory");
    try (PreparedStatement ps = c.prepareStatement("INSERT INTO t VALUES (?)")) {
        ps.setObject(1, ZonedDateTime.of(1500, 6, 1, 0, 0, 0, 0, ZoneOffset.UTC));
        ps.executeUpdate();
    }
    ResultSet rs = s.executeQuery("SELECT toString(dt) FROM t");
    rs.next();
    System.out.println(rs.getString(1)); // 1677-09-21 00:12:43.1452242
}

Configuration

Environment

• Cloud
• Client version: jdbc-v2 0.11.0 (0.10.0 behaves the same)
• Language version: Java 26
• OS: macOS

ClickHouse Server

• ClickHouse Server version: 26.8.34.13
• ClickHouse Server non-default settings, if any: none
• CREATE TABLE statements for tables involved: CREATE TABLE t (dt DateTime64(7, 'UTC')) ENGINE = Memory
• Sample data for all these tables: see the table above

Related: #3127. The workaround suggested there to avoid the JVM time zone shift, setObject(ZonedDateTime), is affected by this bug outside 1677-2262.