Message-ID: <gh-pgjdbc-pgjdbc-1325-c3126551955@github.com>
From: "davecramer (@davecramer)" <noreply+davecramer@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Mon, 28 Jul 2025 10:19:43 +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: davecramer
X-GitHub-Comment-Id: 3126551955
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-3126551955
Content-Type: text/plain; charset=utf-8

> > "Dear database, I handle time zones on the app side. You do not have to worry about it at all"
> > Which I think is a super legit approach :)
> 
> It defeats ad-hoc SQL usage though. In other words, even though the application might try its best to use "safely" such "instants", a user who executes an SQL (reporting, data fix, etc) might fail to deal with such `timestamp` properly. Previously `Instant.class` access failed, so no application could rely on `timestamp -> Instant` conversion. That is why I would like to keep the door closed so the error surfaces at the development time, and users replace `timestamp` to `timestamptz` sooner rather than later if they want accessing it as `Instant`.

I think for a very limited number of people this is a legitimate approach. I'm not sure how to provide correct implementation for most people and this approach in the same driver.