pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: m-van-tilburg (@m-van-tilburg) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: Re: [pgjdbc/pgjdbc] issue #3930: Revert semantic calendar changes introduced with #3837
Date: Thu, 12 Feb 2026 10:13:17 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
> 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)`
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