pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: davecramer (@davecramer) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support
Date: Mon, 28 Jul 2025 10:19:43 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
> > "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.
view thread (25+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://pgjdbc/pgjdbc
Cc: [email protected], [email protected]
Subject: Re: [pgjdbc/pgjdbc] issue #1325: Additional jsr 310 support
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox