Message-ID: <gh-pgjdbc-pgjdbc-1325-c1467783139@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 14 Mar 2023 10:03:53 +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: 1467783139
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-1467783139
Content-Type: text/plain; charset=utf-8

The issue with `ZonedDateTime` is that its `ZoneId` might have several variations:
* `ZoneOffset`. In that case, it is pretty much the same thing as `OffsetDateTime`, so we can support it
* `ZoneRegion`. In that case, the zone can have rules regarding DST, however, the database can't really store the zone name, and it applies the current rules. However, it accepts the time zone name, so the DB does not reject timestamps with named zones.

It looks like we might implement `ZonedDateTime` as `ZonedDateTime.toOffsetDateTime()`, so we convert named zones to offsets.