Message-ID: From: "bokken (@bokken)" To: "pgjdbc/pgjdbc" Date: Thu, 15 Nov 2018 13:40:32 +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: 439043297 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-439043297 Content-Type: text/plain; charset=utf-8 @marschall, I completely agree that the postgresql TIMESTAMP type has complicated mappings into java data types. I guess in light of the inconsistencies I prefer to take the approach of providing similar/unsurprising behavior between the jsr310 types and the legacy types (specifically java.sql.Timestamp, java.util.Date, and Calendar). `Instant` and `java.sql.Timestamp` (and `java.util.Date`) are semantically identical data types. They all represent an exact point in time (to varying degrees of precision), with no regard to time zone. If we support `getObject(int, java.sql.Timestamp,class)` and `getObject(int, java.util.Date.class)` for a TIMESTAMP column, it would seem to be consistent to also support `Instant`. Similarly a `ZonedDateTime` is semantically equivalent to a (populated) `Calendar`. We currently support `getObject(int, Calendar.class)` for TIMESTAMP. While there are certainly drawbacks to the TIMESTAMP data type, my inclination would be to provide as broad support as possible. However, if stricter behavior is desired, I can certainly make those changes. Is this an accurate representation of what you would like to supported? TIMESTAMPTZ - Instant - OffsetDateTime (+0000) - ZonedDateTime (UTC) - LocalDateTime - Timestamp - java.util.Date - java.util.Calendar (system default) TIMESTAMP - ~~Instant~~ - OffsetDateTime (**system default**) - ~~ZonedDateTime (UTC)~~ - LocalDateTime - Timestamp - java.util.Date - java.util.Calendar (system default)