Message-ID: <gh-pgjdbc-pgjdbc-1325-c439479259@github.com>
From: "bokken (@bokken)" <noreply+bokken@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Fri, 16 Nov 2018 18:12:23 +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: 439479259
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-439479259
Content-Type: text/plain; charset=utf-8

> As you can see the time java.sql.Timestamp -> java.time.Instant conversion depends on the JVM default time zone.

I am not sure I agree. What I see is that `LocalDateTime` -> `Timestamp` conversion depends on the JVM default time zone. Which is what the javadoc of the valueOf method in Timestamp[1] indicates:

> The provided LocalDateTime is interpreted as the local date-time in the local time zone.

> Ultimately the project needs to decide. You'll have to explain to users anyway that in order for what they want to work correctly they will have to switch data types. You can only chose if the trigger is either a reproducible exception that always happens and informs them about incompatible data types or a rare and hard to reproduce bug in production that may have already cased data corruption.

I completely agree that the project needs to decide. I somewhat disagree on comparisons of trigger, but I do understand your point.

[1] - https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.time.LocalDateTime-