Subject: [pgjdbc/pgjdbc] PR #3944: doc: clarify that OffsetDateTime return UTC time zone as the backend does not store time zone

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 23 Feb 2026 08:54:32 +0000

Clarifies https://github.com/pgjdbc/pgjdbc/issues/3943

Note: OffsetDateTime UTC behavior is discussed in https://github.com/pgjdbc/pgjdbc/issues/1324.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 23 Feb 2026 11:22:07 +0000

While the backend does not store the TZ. The timestamp does come back with a TZ if you use timestamptz?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 23 Feb 2026 11:38:50 +0000

> The timestamp does come back with a TZ if you use timestamptz

I don't get the question.

---

Well, the backend does send the timezone when using text protocol, and it is discussed in https://github.com/pgjdbc/pgjdbc/issues/1324.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 23 Feb 2026 11:49:59 +0000

Ah, Ok, so we have an issue when using binary. I think for all other timestamps we just assume the client's timezone, no ?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 23 Feb 2026 12:09:00 +0000

Well, `java.sql` types do not have explicit timezone, so we have to convert the value as if it was in "the client's default timezone".
With OffsetDateTime we somehow decided to force UTC, and it causes inconsistency like in #1324.
I think we can use connection timezone when decoding OffsetDateTime, and we can convert UTC binary value into the client's time zone. However, if we ever do so, we should better discuss it in #1324.

This PR just adds extra clarification on the current behavior.