Message-ID: <gh-pgjdbc-pgjdbc-1225-c516382273@github.com>
From: "findepi (@findepi)" <noreply+findepi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 30 Jul 2019 11:38:51 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #1225: Java 8 Time Support for Postgres Arrays
In-Reply-To: <gh-pgjdbc-pgjdbc-1225@github.com>
References: <gh-pgjdbc-pgjdbc-1225@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: findepi
X-GitHub-Comment-Id: 516382273
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 1225
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/1225#issuecomment-516382273
Content-Type: text/plain; charset=utf-8

@davecramer AFAIU, PostgreSQL `timestamp [without time zone]` and Java `LocalDateTime` are both unrelated to any time zone (session, client's, server's).

Time zones are implicated only because JDBC wants you to use `java.sql.Timestamp` which (AFAICT) is always interpreted in correspondence to JVM zone. (This has inherent pitfalls: `java.sql.Timestamp` cannot represent (zone-less) date/time where JVM has forward DST change or forward policy change.)

I've investigated this in Presto SQL (https://github.com/prestosql/presto/issues/37 & related issues and PRs) and my opinion is that we we should use no time zone at all when handling `timestamp` values and treat them as "year/month/day hour/minute/second/millis" "structs".
(I don't know how this plays with PostgreSQL protocol. This is beyond my knowledge.)

cc @electrum