Message-ID: <gh-pgjdbc-pgjdbc-1325-c438847217@github.com>
From: "marschall (@marschall)" <noreply+marschall@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Wed, 14 Nov 2018 22:44:45 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support
In-Reply-To: <gh-pgjdbc-pgjdbc-1325@github.com>
References: <gh-pgjdbc-pgjdbc-1325@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: marschall
X-GitHub-Comment-Id: 438847217
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2018-11-15T07:29:32Z
X-GitHub-Issue: 1325
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/1325#issuecomment-438847217
Content-Type: text/plain; charset=utf-8

These are my personal views:
* Supporting Instant for TIMESTAMPTZ is fine. It is not covered by the JDBC 4.2 specification but it is semantically equivalent. I find it not particularly useful as I find Instant a not particularly useful datatype, it's just an int and a long.
* I am against supporting Instant for TIMESTAMP. These are semantically different data types. When converting between Instant and TIMESTAMP you have two options and both seem wrong
  * use the system default time zone which means you'll get different values/instants depending on the system default time zone. Additionally in case of DST transitions you can get reorderings and the duration between instants can change .
  * use UTC which adds semantics to TIMESTAMP which it doesn't have and will possibly users as the value stored on the database is different from the local time
* Supporting ZonedDateTime for TIMESTAMPTZ is fine. It is not covered by the JDBC 4.2 specification but it is semantically equivalent. I would also use UTC as that's what Postgres is storing. There is potential here as well for user confusion as they will likely get a different offset back. However they will get the same instant and that's consistent with the current behavior of OffsetDateTime.
* I am against supporting ZonedDateTime for TIMESTAMP. These are semantically different data types. If you're using the default zone id you will get different instants depending on the default zone id. Also in the case of DST transitions you can get reorderings and some of the conversions are ambiguous as there are two possible offsets to chose from.