[Java][FlightSQL] JDBC driver returns pre-1970 dates one day late when a Calendar is supplied

### Describe the bug, including details regarding any error messages, version, and platform.

`DateTimeUtils.getTimestampValue(long)` splits epoch milliseconds into an epoch day and a time within that day. The old code used `/` and `%`:

```java
public static Timestamp getTimestampValue(long millisWithCalendar) {
long milliseconds = millisWithCalendar;
if (milliseconds < 0) {
// LocalTime#ofNanoDay only accepts positive values
milliseconds -= ((milliseconds / MILLIS_PER_DAY) - 1) * MILLIS_PER_DAY;
}

return Timestamp.valueOf(
LocalDateTime.of(
LocalDate.ofEpochDay(millisWithCalendar / MILLIS_PER_DAY),
LocalTime.ofNanoOfDay(TimeUnit.MILLISECONDS.toNanos(milliseconds % MILLIS_PER_DAY))));
}
```

Both operators round toward zero. For dates before 1970, the code adjusted the negative remainder because `LocalTime.ofNanoOfDay` rejects it. It did not adjust the epoch day. When the input was negative and not exactly midnight, the day and remainder then referred to different days. The date came back one day late.

For example, `-618102000000` ms is 1950-06-01 01:00:00 UTC. Division by `86400000` truncates to `-7153`, which is 1950-06-02. The remainder is `3600000` ms, or 01:00. The old result was 1950-06-02 01:00:00. `Math.floorDiv` returns `-7154`, the correct epoch day for 1950-06-01.

### How this happens in JDBC

`ArrowFlightJdbcDateVectorAccessor.getDate(Calendar)` applies the calendar offset before calling this method. A DATE starts at midnight, but any difference between the supplied calendar zone and the JVM default moves it away from midnight. Passing a `Calendar` is the documented way to read a date in a specific zone. As a result, every pre-1970 date read this way came back one day late. Any non-zero offset can expose the bug. Historical offsets can include seconds, such as +05:53:28.

The existing negative test used `-618105600000`, exactly 1950-06-01 00:00:00 UTC. At midnight, truncating division and floor division agree, so that test could not expose the bug.

The fix uses `Math.floorDiv` and `Math.floorMod` for both parts and removes the manual adjustment. Positive values behave as before. A test now covers 1950-06-01 01:00:00 UTC.

This affects `flight-sql-jdbc-core` on `main` and in 19.0.0. It is platform independent. Issues #732 and #324 cover broader timestamp and time-zone behavior. This report is only about the integer-division bug above.

Bắt đầu với DateTimeUtils.getTimestampValue(long), sau đó kiểm tra ArrowFlightJdbcDateVectorAccessor.getDate(Calendar) và bài kiểm thử hiện có cho ngày âm. Tái hiện trường hợp 1950-06-01 01:00:00 UTC với một độ lệch lịch và xác minh rằng các phép tính ngày epoch và thời gian sử dụng các ranh giới ngày tương ứng. Hoàn thành khi các ngày trước năm 1970 với các lịch được cung cấp trả về đúng ngày và bài kiểm thử hồi quy đạt.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.