Message-ID: From: "eirikbakke (@eirikbakke)" To: "pgjdbc/pgjdbc" Date: Thu, 05 Jun 2025 01:27:38 +0000 Subject: Re: [pgjdbc/pgjdbc] issue #2311: Why is client time zone not configurable? In-Reply-To: References: List-Id: X-GitHub-Author-Login: eirikbakke X-GitHub-Comment-Id: 2942403762 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 2311 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/2311#issuecomment-2942403762 Content-Type: text/plain; charset=utf-8 @vlsi That example makes sense; it makes it clear why TimeZone can't be set to GMT by default without breaking backwards compatibility. Possible solutions (just brainstorming): 1) The already-suggested idea of letting the TimeZone parameter be set to an arbitrary value via a JDBC URL parameter or connection property. 2) Or, a simpler boolean JDBC URL property that _only_ exposes the option of setting TimeZone=GMT, rather than to an arbitrary time zone. But I could imagine cases where someone in Asia/Kolkata would want to connect with TimeZone=Asia/Calcutta to make some existing application "just work", without worrying about potential effects of switching to GMT. So maybe option (1) is better. 3) Or, keep the current behavior, but detect the 'invalid value for parameter "TimeZone"' error from the server and retry the connection automatically with an alternative time zone name for the known special cases (Kiev and Kyiv, Kolkata and Calcutta...). 4) Or, like (3), but connect always with TimeZone=GMT and use "SET SESSION TIME ZONE" to set the time zone instead, catching errors on the latter command. (Avoids re-authenticating etc., but means an extra network round trip in these time zones.) In any case, it should probably be ensured that ResultSet.getTimestamp does not get affected by any change in the TimeZone parameter.