Postgres Timestamp Vs Timestamptz //top\\ May 2026

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!) |

If you change your session time zone to 'Asia/Tokyo' (UTC+9) and read the table:

If you care when something happened, use TIMESTAMPTZ . Your future self (and your global users) will thank you. Have a horror story about timestamps gone wrong? Share it in the comments below! postgres timestamp vs timestamptz

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

| Column | What PostgreSQL stores internally | |--------|----------------------------------| | ts_native | 2025-04-14 14:00:00 (exact text, no zone info) | | ts_tz | A UTC timestamp: 2025-04-14 18:00:00+00 (because 2pm ET = 6pm UTC) | CREATE TABLE events ( id SERIAL, local_start TIMESTAMPTZ,

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 – .

-- Insert the same "local" value INSERT INTO time_test VALUES ('2025-04-14 14:00:00', '2025-04-14 14:00:00'); Share it in the comments below

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.