Message-ID: <gh-pgjdbc-pgjdbc-1325-c439051121@github.com>
From: "bokken (@bokken)" <noreply+bokken@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Thu, 15 Nov 2018 14:06:16 +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: bokken
X-GitHub-Comment-Id: 439051121
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-439051121
Content-Type: text/plain; charset=utf-8

`Timestamp` as a data type is not bound the the jvm time zone. The jdbc api for setTimestamp and getTimestamp have specified the use of the default timezone when no Calendar is provided. The `toString` implementation of `java.util.Date` (and thus java.sql.Timestamp) use the timezone of the jvm when constructing a String.

The example you give show both java.sql.Timestamp and java.time.Instant having the same behavior, which was my point of them being the same data type.

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

I certainly understand that there are challenges with the TIMESTAMP datatype and that users should be encouraged to use TIMESTAMPTZ. But should this project "force" that by limiting the support for TIMESTAMP with the introduction of new data types?