Message-ID: From: "eirikbakke (@eirikbakke)" To: "pgjdbc/pgjdbc" Date: Tue, 03 Jun 2025 15:57:15 +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: 2936096930 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-2936096930 Content-Type: text/plain; charset=utf-8 The JDBC driver should probably not assume that the client and the server has exactly the same version of the time zone database installed. Often, client applications must be able to connect to servers of many different versions, including servers that depend on older versions of the time zone database. As seen in https://github.com/pgjdbc/pgjdbc/issues/3642 , this can cause connections to fail with the current approach. Developers of client applications often do not have control over the server version and vice versa. Even when the name of time zones match between client and server, there can be changes in DST transition dates from year to year. If the client and server has a different idea of when DST transitions happen, then off-by-one-hour errors could start appearing silently. This seems like an avoidable problem; since PostgreSQL always stores timestamptz values at UTC, there should really be no need for conversion to happen on the server side at all. Ideally the JDBC driver would connect with TimeZone=GMT, and perform any necessary conversions on the client side, e.g. when getting a java.sql.Timestamp value from a ResultSet. (I realize that the newer java.sql.Timestamp.toInstant() API makes all the conversions irrelevant, but obviously there is a lot of older code that uses java.sql.Timestamp directly.)