"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+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.
From:
Bryn Llewellyn Date: Subject:
Surprising results from tests intended to show the difference in semantics between transaction_timestamp(), statement_timestamp(), and clock_timestamp()
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.
