pgjdbc/pgjdbc GitHub issues and pull requests (mirror)  

help / color / mirror / Atom feed

From: bokken (@bokken) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support
Date: Thu, 15 Nov 2018 13:40:32 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

@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)

view thread (25+ 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 #1325: Additional jsr 310 support
  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