Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Mon, 2025-01-27 at 07:51 +0000, PG Doc comments form wrote:
>> Suggestion: Assuming my understanding is accurate - clarify for the reader
>> that time zone offset is lost (after conversion to UTC). At risk of stating
>> the obvious: "timestamp with time zone" is a rather misleading name.
>> "timestamp coerced to UTC" or something would be more accurate.
> Your understanding is correct.
> I personally think of "timestamp with time zone" as an "absolute timestamp".
Yes. The datatype's behavior is not what you would expect from the
SQL standard, which makes our choice of the standard-derived name
rather unfortunate. That choice is well over 25 years old though,
so there's not much chance of changing it now.
> To preserve the original time zone that was entered, you'd have to store it
> in a separate database column.
The other problem is: what are you gonna store exactly? A numeric
offset from UTC is unambiguous but doesn't bring much to the table
compared to what we do now. A time zone name is a possibility,
but (a) that's bulky and (b) the politicians keep changing the
DST laws, so the meaning could change. In certain cases like
appointment calendars, tracking local law is just what you want
... but in cases like flight schedules, probably not.
regards, tom lane
