Message-ID: <gh-pgjdbc-pgjdbc-1325-c3126487910@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Mon, 28 Jul 2025 10:01:42 +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: vlsi
X-GitHub-Comment-Id: 3126487910
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-3126487910
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`.