Hi Bruce,
Thanks for your reply. Yes I think it does need to be stated more boldly
- from a "Poka-Yoke" perspective (and despite using Postgresql for
years), I didn't properly understand it the first time.
I think it's a gotcha, because, to me, the name suggests a different
behaviour.
I understood "timestamp with timezone" as "a data type which stores the
timestamp, and stores the timezone WITH (i.e. alongside) it".
So I think it deserves a "Caution" or "note" boxout, or at least to have
words "the originally stated or assumed time zone is not retained." made
in bold.
While looking at the docs, I can also see 3 other things that would be
helpful to add:
1. How to actually store "timestamp_and_timezone" ? (i.e. I want to
store the UTC value, and I want to store and retrieve the original
offset). Presumably the answer is to store both timestamptz AND the
integer tz_offset (is there a "timezone" datatype, or should that just
be a string?)
2. How to store a general timestamp in NO timezone (for example, to
store the concept that "Armistice Day is remembered at 11:00 on 11/11" -
which is the same for everyone across the world, even though the
underlying UTC value is undefined). Presumably you could store this as 2
columns (date, time), but there's no compound "date+time" type, and it
would not be the same as timestamp.
3. While the docs caution against using "time with timezone", they don't
recommend whether to use "timestamp" or "timestamptz" as the default.
Such a recommendation might be helpful.
Best wishes,
Richard
On 2026-05-13 01:19, Bruce Momjian wrote:
On Wed, Apr 22, 2026 at 11:40:49AM +0000, PG Doc comments form wrote:
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/18/datatype-datetime.html
Description:
Hi,
Just a small bit of feedback on this page:
https://www.postgresql.org/docs/current/datatype-datetime.html
There is a gotcha for the unwary, in that it does not preserve the
original
timezone after the data is recorded.
The user needs to understand that timestamp with timezone is
performing
implicit conversion for them, but it does not save the TZ value.
One might, naively, expect it to do the "obvious" thing, storing the
original timezone alongside the timestamp, and therefore
allow you to query the data and discover what the timezone was when
the data
was input.
(i.e. the on-disk representation of "17th May at 4pm New York" should
be
different from "17th May at 1pm in Los Angeles", and that a query
should be able to do something like not just the UTC value in the
local
timezone, but also the fact that this date was recorded from the
perspective
of a New Yorker).
Or in other words, one might expect that:
SELECT EXTRACT (timezone FROM '2026-04-16 13:00:00+09'::timestamptz);
should be able to tell me the "+09", regardless of my own local time.
May I suggest adding a "Caution" to draw greater attention to this
fact, and
recommending an alternative if there is one.
The documentation says:
https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-DATETIME-INPUT
For timestamp with time zone values, an input string that
includes an explicit time zone will be converted to UTC
(Universal Coordinated Time) using the appropriate offset for
that time zone. If no time zone is stated in the input string,
then it is assumed to be in the time zone indicated by the
system's TimeZone parameter, and is converted to UTC using the
--> offset for the timezone zone. In either case, the value is stored
--> internally as UTC, and the originally stated or assumed time zone
--> is not retained.
Does this need to be stated more boldly?
