Message-ID: <gh-pgjdbc-pgjdbc-3930-c3889952702@github.com>
From: "m-van-tilburg (@m-van-tilburg)" <noreply+m-van-tilburg@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Thu, 12 Feb 2026 10:13:17 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3930: Revert semantic calendar changes introduced with #3837
In-Reply-To: <gh-pgjdbc-pgjdbc-3930@github.com>
References: <gh-pgjdbc-pgjdbc-3930@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: m-van-tilburg
X-GitHub-Comment-Id: 3889952702
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2026-02-12T10:23:32Z
X-GitHub-Issue: 3930
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3930#issuecomment-3889952702
Content-Type: text/plain; charset=utf-8

> Let me keep it as simple as possible.
> 
> **IF** I do `insert into testtable(this_is_a_date) values ('1000-01-01')` (or equivalent for Oracle with `TO_DATE`).
> 
> **THEN** I expect the following code to print only `true`, and that 7 times.
> 
> ```
> String select = "SELECT * FROM TESTTABLE";
> statement = connection.prepareStatement(select);
> resultSet = statement.executeQuery();
> 
> while (resultSet.next()) {
>     java.sql.Date date = resultSet.getDate("this_is_a_date");
>     String string = resultSet.getString("this_is_a_date").split(" ")[0]; // Oracle returns "1000-01-01 00:00:00"
>     String[] split = string.split("-");
>     LocalDate ld = resultSet.getObject("this_is_a_date", LocalDate.class);
> 
>     System.out.println(date.equals(java.sql.Date.valueOf(string)));
>     System.out.println(date.equals(java.sql.Date.valueOf(ld)));
>     System.out.println(date.toString().equals(string));
>     System.out.println(date.toLocalDate().equals(ld));
>     System.out.println(date.toLocalDate().toString().equals(string));
>     System.out.println(ld.toString().equals(string));
>     System.out.println(ld.equals(LocalDate.of(Integer.parseInt(split[0]), Integer.parseInt(split[1]), Integer.parseInt(split[2]))));
> }
> ```
> 
> **RESULTS**
> 
> * `com.microsoft.sqlserver:mssql-jdbc:13.3.1.jre11-preview` → 7 × `true`
> * `com.oracle.database.jdbc:ojdbc17:23.26.1.0.0` → 7 × `true`
> * `org.postgresql:postgresql:42.7.8` → 7 × `true`
> * `org.postgresql:postgresql:42.7.9` → 5 × `false` followed by 2 × `true`

I can understand why you would have expected this to be correct before reading the information in this issue. I don't understand it at this point, besides you wanting it to work as it did before. If you don't believe what I am saying, look at the implementation of the `java.util.Date` and `java.sql.Date` methods your calling. Per result this is what happens (keeping in mind that the database is proleptic Gregorian as the SQL standard dictates):

1. "1000-01-01" will be parsed using the Julian calendar (because of `new Date(int, int, int)`) resulting in an incorrect timestamp
2. LocalDate(1000,1,1) will be parsed using the Julian calendar (because of `new Date(int, int, int)`) resulting in an incorrect timestamp
3. The (correct) database timestamp is formatted using the Julian calendar (because of `Date.toString()`) resulting in an incorrect date String
4. `date.toLocalDate()` will use Julian calendar based values as input for the `LocalDate` resulting in an incorrect `LocalDate`
5. same as the previous one except your calling `toString()` on the already incorrect `LocalDate` object
6. correct, because you used `resultset.getObject(String, LocalDate)` to get it so it is (and was in previous versions) correctly returning a proleptic Gregorian value
7. correct, although I am not sure why you test splitting a String against `LocalDate.of(int, int, int)`