My 2-cents.

"Time stamp with time zone" is a terrible name for the data type. "Point in
time" would be better but we are stuck with historical baggage in that
regard. The following are equivalent points in time (AKA timesamptz):
2021-09-21 12:34:56-07
Tue 21 Sep 2021 12:34:56 PM PDT
2021-09-21 12:34:56+00
2021-09-21 12:34:56+08:45 (Yes, Australia and some other areas have
non-full-hour offsets).
1632252896 (Epoch)

The server's internal representation of timestamptz is completely
irrelevant except to the PostgreSQL developers. Who cares if it's UTC- it
can be in micro-gerbils as far as users are concerned. All that matters is
that the server can store a point-in-time value and can return that value
represented in the time zone and format that the user requests.

I have never personally encountered a situation where I needed to track the
timezone of the person/process that inserted point-in-time data but I
almost always encounter the need to retrieve point-in-time data represented
in the end-user's desired zone and locale/format (join the conference call
at, the rocket launch is scheduled for, ...). If needed for a specific
case, the user can always include a column indicating the desired offset or
the time-zone to use to determine the offset, whichever is better suited
for their needs.

Cheers,
Steve

Reply via email to