From 005e0fab5173b2a3c28645306a419582c1091eb5 Mon Sep 17 00:00:00 2001 From: Danny Xu Date: Tue, 3 Nov 2026 14:27:32 +0000 Subject: [PATCH] Drop the session TimeZone conversion from stdlib initValueFuncs resolved ParameterStatus("TimeZone") through time.LoadLocation for every timestamptz value scanned. Go reparses the zoneinfo file on each call for a named zone, so the same 100k-cell result cost 484ms and 133MB of allocation on a non-UTC database against 23ms and 2.3MB on a UTC one. The per-value lookup bought no accuracy for that. PostgreSQL reports a TimeZone change at command completion, after the rows, so every value in one result set resolves the same setting: a statement that changes the zone mid-flight still decodes its own rows under the old one. Callers can read the setting once per statement and apply the location themselves, which also lets them fall back instead of failing a query whose TimeZone is a POSIX specification time.LoadLocation cannot parse, such as "+08:00" or "EST5EDT,M3.2.0/2,M11.1.0/2". This reapplies #3, which #4 reverted so that an unrelated dependency bump carried no behavior change. Co-Authored-By: Claude Opus 5 --- stdlib/sql.go | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/stdlib/sql.go b/stdlib/sql.go index 8f8940c94..b1907c484 100644 --- a/stdlib/sql.go +++ b/stdlib/sql.go @@ -852,16 +852,6 @@ func (r *Rows) initValueFuncs() { if err != nil { return nil, err } - - if d.InfinityModifier == pgtype.Finite { - timezone := r.conn.conn.PgConn().ParameterStatus("TimeZone") - lc, err := time.LoadLocation(timezone) - if err != nil { - return nil, err - } - d.Time = d.Time.In(lc) - } - return d.Value() } case pgtype.XMLOID: