Message-ID: From: "bokken (@bokken)" To: "pgjdbc/pgjdbc" Date: Mon, 28 Jul 2025 12:55:29 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support In-Reply-To: References: List-Id: X-GitHub-Author-Login: bokken X-GitHub-Comment-Id: 3127109948 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 1325 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/1325#issuecomment-3127109948 Content-Type: text/plain; charset=utf-8 I think that linked issue was adding `OffsetTime` - and `OffsetDateTime` even predates it - but the overall point that it has been around for a long time remains. This is shaking loose some memories. The jdbc 4.2 spec explicitly called out `OffsetDateTime` - and the work done to support jdbc 4.2 only covered the datatypes explicitly listed. `timestamptz` maps very nicely to `Instant` and `java.sql.Timestamp`/`java.util.Date` - in that all are an point in time. `OffsetDateTime` and `ZonedDateTime` add the context of specific offset and full time zone respectively. Because of jdbc 4.2, we pretty much have to support `OffsetDateTime` - we can extend that to `ZonedDateTime`, but since the database does not support either timezone or offset data, there could be value in not supporting additional types not required by the spec which imply more functionality than the database can provide. There is already repeated confusion about what `timestamptz` actually stores. If we are going to do `ZonedDateTime`, there might be value in making the ZoneId exactly `UTC` rather than just inheriting from `OffsetDateTime` and offset of 0.