https://www.postgresscripts.com/tags/timestamptz/Recent content in Timestamptz on Postgres ScriptsHugo -- gohugo.ioenPostgresScripts.comMon, 15 Jun 2026 00:00:00 +0000https://www.postgresscripts.com/post/timestamptz-and-tzdata-updates-avoiding-shifted-postgresql-timestamps/Mon, 15 Jun 2026 00:00:00 +0000https://www.postgresscripts.com/post/timestamptz-and-tzdata-updates-avoiding-shifted-postgresql-timestamps/ <h2 id="timestamptz-and-tzdata-avoid-shifted-postgresql-timestamps">timestamptz and tzdata: Avoid Shifted PostgreSQL Timestamps</h2> <p>PostgreSQL stores every <code>timestamptz</code> value as UTC and converts it to the session's time zone only at display time. That design is correct and elegant — until a <code>tzdata</code> update changes the offset rules for a region, at which point timestamps inserted under the old rules can render at a different local time than the day they were recorded.</p> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1012089347386563" crossorigin="anonymous"></script> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-1012089347386563" data-ad-slot="7945792173" data-ad-format="auto" data-full-width-responsive="true"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> <h2 id="purpose-and-overview">Purpose and Overview</h2> <p><code>timestamp with time zone</code>, almost always written <code>timestamptz</code>, is the type most applications should use for points in time. The name is slightly misleading: the column does not store a time zone. It stores a single absolute instant as UTC. When you insert a value with an explicit offset, PostgreSQL converts it to UTC for storage and discards the original zone; when you read it back, it converts from UTC to whatever the session's <code>TimeZone</code> parameter is set to. Two clients in different zones see the same instant rendered in their own local time, and that is exactly the behavior you want.</p>