Message-ID: <gh-pgjdbc-pgjdbc-1325-c439047447@github.com>
From: "marschall (@marschall)" <noreply+marschall@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Thu, 15 Nov 2018 13:55:06 +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: 439047447
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-439047447
Content-Type: text/plain; charset=utf-8

@bokken 

> 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.

This is unfortunately not sure. java.sql.Timestamp is bound to the JVM default time zone. Let's say you have `2018-11-15T14:48` on the database and your JVM default time zone is +1 you will get a Timestamp and instant for `2018-11-15T14:48+01:00`. If your JVM default time zone is +2 you get a Timestamp and instant for `2018-11-15T14:48+02:00` which is different.

I feel allowing these kinds of conversions will further perpetuate the subtle time zone bugs that people are complaining about with the existing java.sql and java.util.Date APIs.