Postgres Timestamp Vs Timestamptz 2021 Info

Now, what is stored?

-- Insert the same "local" value INSERT INTO time_test VALUES ('2025-04-14 14:00:00', '2025-04-14 14:00:00'); postgres timestamp vs timestamptz

Always use in your application code. Quick Decision Flowchart Is this a single, absolute moment in time? │ ├── YES (e.g., created_at, updated_at, event start time for global users) │ → Use TIMESTAMPTZ │ └── NO (e.g., "Every day at 9 AM" recurring alarm) → Use TIMESTAMP + store time zone separately in another column Pro Tip: TIMESTAMPTZ Does NOT Store the Time Zone This is the #1 misunderstanding. TIMESTAMPTZ does not save 'America/Chicago' or '+05:30' . It converts your input to UTC, stores UTC, and discards the original offset. Now, what is stored

CREATE TABLE events ( id SERIAL, local_start TIMESTAMPTZ, -- absolute moment in UTC user_time_zone TEXT -- 'America/Los_Angeles' ); | Feature | TIMESTAMP | TIMESTAMPTZ | |---------|-------------|----------------| | Time zone awareness | ❌ No | ✅ Yes (UTC internally) | | Changes with client time zone | ❌ No | ✅ Yes (on output) | | Safe for global apps | ❌ Risky | ✅ Safe | | Storage size | 8 bytes | 8 bytes (same!) | │ ├── YES (e

If your column is TIMESTAMPTZ , but your application sends a naive timestamp, PostgreSQL will assume the timestamp is in your session's time zone. If your server is in UTC and your user is in Sydney – .

Chances are, you chose the wrong PostgreSQL temporal data type.