pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: AFulgens (@AFulgens) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: [pgjdbc/pgjdbc] issue #3930: Revert semantic calendar changes introduced with #3837
Date: Thu, 05 Feb 2026 15:30:50 +0000
Message-ID: <[email protected]> (raw)
**Describe the issue**
The change of calendar handling done in #3837 results in pseudo data corruption (as in: the returned results are different than the stored values) across JDBC versions before and after 42.7.9.
**Driver Version?**
42.7.8 vs. 42.7.9
**Java Version?**
Not relevant, but I tested with 21 (21.0.6+7-LTS)
**OS Version?**
Not relevant, but I tested on Windows 11 23H2.
**PostgreSQL Version?**
Not relevant, but I tested with the Docker image `postgres:17-alpine` from Dockerhub, image updated today (2026-02-05).
**To Reproduce**
Steps to reproduce the behaviour:
- Create a database with a table that contains a date (or timestamp) field.
- Insert `1000-01-02` with org.postgresql:postgresql:42.7.9 into this table.
- Query the table with a prior version of the driver
- ⚠️ see incorrect date, namely `1000-01-07`.
The other way around:
- Create a database with a table that contains a date (or timestamp) field.
- Insert `1000-01-02` with org.postgresql:postgresql:42.7.8 or prior into this table.
- Query the table with 42.7.9 version of the driver
- ⚠️ see incorrect date, namely `999-12-28`.
The following code can be used as stub:
```
Connection connection = DriverManager.getConnection(...);
PreparedStatement stmt = connection.prepareStatement("insert into testtable(this_is_a_date) values (?)");
stmt.setDate(1, java.sql.Date.valueOf(LocalDate.of(1000, 1, 2)));
stmt.executeUpdate();
```
Please also note that `java.sql.Date.valueOf(LocalDate.of(1000, 1, 2))` is just for convenience. The same happens regardless of used Java-side representation, i.e., all of these yield the same results:
- `java.sql.Date.valueOf(LocalDate.of(1000, 1, 2)`
- `java.sql.Date.valueOf(OffsetDateTime.of(1000, 1, 2, 0, 0, 0, 0, ZoneOffset.UTC).toLocalDate())`
- `new java.sql.Date(-30610137600000L)` (if you use this for persisting data with the driver 42.7.9, you will see `1000-01-02` with prior drivers and `999-12-28` with 42.7.9, which what the original change request wanted to achieve)
**Expected behaviour**
This means "seemingly random" "data corruption" occurs for every stored date and timestamp in PostgreSQL databases for time-instances that do not overlap on Gregorian and Julian calendars (as per #3837), i.e., everything before the middle of October, 1582.
"Seemingly random" "data corruption" should not occur at the JDBC-driver level just because I update a patch version. This could be discussed for a major release, but that would still mean that I have to execute data migration scripts in my database to "correct" the already existing data.
I understand that semantically the prior behaviour is incorrect, but consistency of already existing data should take priority in my opinion. What effectively happened with #3837 is that **the semantics of historical dates and timestamps is changed on the JDBC driver level**. This will cause a lot of issues with databases already containing such historical data.
The current state of affairs is even worse: in many DB-browser products the version 42.7.9 of the driver is not yet rolled out, but if Java clients with updated drivers start to commit data into these databases, then the Java clients are seeing a consistent world for the new data ("corrupted" data for anything that existed formerly), but the DB-browser (DBeaver, JetBrains products, etc.) will see a consistent world for the old data and "corrupted" values for anything inserted recently. On the contrary, if I insert a historical dates manually via the DB-browser product, it will display it consistently, but Java clients will read a different value.
**Logs**
N/A
view thread (24+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://pgjdbc/pgjdbc
Cc: [email protected], [email protected]
Subject: Re: [pgjdbc/pgjdbc] issue #3930: Revert semantic calendar changes introduced with #3837
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox