Skip to content

fix(jdbc): honor the supplied Calendar in date/time overloads - #260

Merged
magnusp merged 1 commit into
fix/i250-label-getter-checksfrom
fix/i237-honor-calendar
Oct 30, 2026
Merged

magnusp merged 1 commit into
fix/i250-label-getter-checksfrom
fix/i237-honor-calendar

Conversation

@magnusp

@magnusp magnusp commented Oct 30, 2026

Copy link
Copy Markdown
Owner

Why

The nine Calendar overloads of setDate/setTime/setTimestamp and getDate/getTime/getTimestamp ignored their Calendar and delegated to the default-zone overload. A caller passing Asia/Tokyo got the same text and the same instant as a caller passing UTC, which contradicts JDBC, H2, PostgreSQL, and xerial.

What changed

  • Threaded a ZoneId through SqliteDateTimeValues.from, epochMillisToLocalDateTime, and parseSqliteDateTime, keeping the system-default overloads so the non-Calendar path is unchanged. Text with an explicit offset is a fixed instant converted into the zone; naive text is wall-clock time in the zone; INTEGER is epoch millis; FLOAT is a Julian day.
  • Getters now build java.sql.Date/Time/Timestamp from the zone-local fields: midnight of the local date, 1970-01-01 plus the local time, and the full local date-time with nanos preserved.
  • Setters render the instant in the calendar zone while keeping the existing text forms: yyyy-MM-dd, HH:mm:ss, and yyyy-MM-dd HH:mm:ss[.fraction] with .0 for zero nanos, matching Timestamp.toString(). setTimestamp does not go through JdbcValueConverter.formatTimestamp.
  • A null Calendar means the JVM default zone and delegates to the existing overload; it never throws.
  • Added unit coverage for zone-dependent getters and setters, offset text, INTEGER and Julian-day inputs, null calendars, null values, nanos, and a non-Gregorian calendar field system.

Blast radius

Only the nine Calendar overloads change. The default-zone overloads, setObject, getObject(..., LocalDate.class), and the Appendix B conversion paths are untouched, so existing text and instants are unchanged. A Timestamp still carries no zone: the calendar only decides which instant naive stored text denotes.

Verification

  • ./mvnw -pl libsql-jdbc -Dtest='LibsqlResultSetTest,LibsqlPreparedStatementTest' test: 99 tests, 0 failures.
  • ./mvnw clean verify: 1524 JDBC unit tests (1559 unit tests across the reactor), 192 itests, 271 conformance tests with 7 skipped, 0 failures. This includes the vendored StatementTest#nullDate and #emptyDate.
  • ./mvnw spotless:check passes.

Fixes #237

@magnusp magnusp changed the title fix(jdbc): honor the supplied Calendar in date/time overloads (#237) fix(jdbc): honor the supplied Calendar in date/time overloads Oct 30, 2026
@magnusp
magnusp force-pushed the fix/i237-honor-calendar branch from eb0afff to 6570295 Compare October 30, 2026 23:31
@magnusp
magnusp changed the base branch from main to fix/i250-label-getter-checks October 30, 2026 23:31
@magnusp
magnusp added this pull request to stack #265 October 30, 2026 23:31
@magnusp
magnusp force-pushed the fix/i237-honor-calendar branch from 6570295 to cb8da85 Compare October 30, 2026 23:33
@magnusp
magnusp force-pushed the fix/i237-honor-calendar branch from cb8da85 to 5a22b79 Compare October 30, 2026 23:42
@magnusp
magnusp force-pushed the fix/i237-honor-calendar branch from 5a22b79 to 76c8765 Compare October 30, 2026 23:48
@magnusp
magnusp merged commit 8ce45c0 into main Oct 30, 2026
6 checks passed
@magnusp
magnusp deleted the fix/i237-honor-calendar branch October 30, 2026 23:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Date/Time/Timestamp Calendar overloads silently ignore the supplied Calendar

1 participant