pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feed[pgjdbc/pgjdbc] issue #2834: LocalTime.MAX is more precise than postgresql, causing a possible overflow to the next day
4+ messages / 3 participants
[nested] [flat]
* [pgjdbc/pgjdbc] issue #2834: LocalTime.MAX is more precise than postgresql, causing a possible overflow to the next day
@ 2023-02-28 20:31 "tsayao (@tsayao)" <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: tsayao (@tsayao) @ 2023-02-28 20:31 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
**Describe the issue**
I am using Hibernate (5.6.14) with Spring Data JPA and pgjdbc 42.5.4.
When querying a column that is mapped to `LocalDateTime` with `LocalDate.atTime(LocalTime.MAX)` it returns results with the next day at 00:00:00.000000.
`LocalTime.MAX` is implemented as:
`MAX = new LocalTime(23, 59, 59, 999999999);`
**Driver Version?**
42.5.4
**Java Version?**
17.0.4
**OS Version?**
Linux Ubuntu 20.04
**PostgreSQL Version?**
14.5
**To Reproduce**
```
create table test (
col timestamp
);
insert into test(col) values ('2023-03-01 00:00:00.000000');
insert into test(col) values ('2023-02-28 23:59:59.999999');
```
```
public class Main {
public static void main(String[] args) throws Exception {
String url = "jdbc:postgresql://localhost:5432/database";
Properties props = new Properties();
props.setProperty("user", "login");
props.setProperty("password", "pass");
try (Connection conn = DriverManager.getConnection(url, props)) {
try (var stmt = conn.prepareStatement("select col from test where col = ?")) {
stmt.setTimestamp(1, Timestamp.valueOf(LocalDate.of(2023, 2, 28).atTime(LocalTime.MAX)));
try (ResultSet rs = stmt.executeQuery()) {
if (rs.next())
System.out.println("Get String: " + rs.getString(1));
}
}
}
}
}
```
Prints out:
`Get String: 2023-03-01 00:00:00`
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #2834: LocalTime.MAX is more precise than postgresql, causing a possible overflow to the next day
@ 2023-02-28 20:42 "davecramer (@davecramer)" <[email protected]>
2 siblings, 0 replies; 4+ messages in thread
From: davecramer (@davecramer) @ 2023-02-28 20:42 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Thanks for the report. Will look into it.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #2834: LocalTime.MAX is more precise than postgresql, causing a possible overflow to the next day
@ 2026-03-13 14:31 "motofix (@motofix)" <[email protected]>
2 siblings, 0 replies; 4+ messages in thread
From: motofix (@motofix) @ 2026-03-13 14:31 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
I'm not sure that the issue is specific to `pgjdbc`, as `psql` have the same behaviour:
```none
create table test (
col timestamp
);
insert into test(col) values ('2023-03-01 00:00:00.000000');
insert into test(col) values ('2023-02-28 23:59:59.999999');
select col from test where col = '2023-02-28 23:59:59.999999999';
col
---------------------
2023-03-01 00:00:00
(1 row)
```
Knowing this nanoseconds rounding to microseconds limitation, maybe `pgjdbc` should truncate to microseconds ?
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #2834: LocalTime.MAX is more precise than postgresql, causing a possible overflow to the next day
@ 2026-03-17 10:48 "davecramer (@davecramer)" <[email protected]>
2 siblings, 0 replies; 4+ messages in thread
From: davecramer (@davecramer) @ 2026-03-17 10:48 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Touching time/date has historically been problematic. If this isn't a glaring bug, I'm inclined to let sleeping dogs lay.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-03-17 10:48 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-02-28 20:31 [pgjdbc/pgjdbc] issue #2834: LocalTime.MAX is more precise than postgresql, causing a possible overflow to the next day "tsayao (@tsayao)" <[email protected]>
2023-02-28 20:42 ` "davecramer (@davecramer)" <[email protected]>
2026-03-13 14:31 ` "motofix (@motofix)" <[email protected]>
2026-03-17 10:48 ` "davecramer (@davecramer)" <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox