timestamptz_postgres_type_demo

demo.sql

-- this table has a `timestamp_no_tz` column (which allows bugs) and `timestamp_tz` column (which protects against bugs)
create table tz_type_example
(
    timestamp_no_tz timestamp(0)   not null,
    timestamp_tz    timestamptz(0) not null
);

-- inserting the same timestamp in a human-readable format into both columns
insert into tz_type_example values ('2026-01-01 10:00:00 +05:00', '2026-01-01 10:00:00 +05:00'); -- same as 2026-01-01 05:00:00 +00:00

select * from tz_type_example;
-- When we select the timestamps back, the timestamp from the `timestamp_no_tz` column "lost" 5 hours (see the dump below)
-- However, the timestamp from the "timestamp_tz" is correct.
-- We could normalise the input on the application side to solve this.
-- But using the `timestamptz` solves this once and for all future table interactions, which makes the application less error-prone.

-- timestamp_no_tz,timestamp_tz
-- 2026-01-01 10:00:00,2026-01-01 05:00:00 +00:00