Postgres Timestamp Vs Timestamptz May 2026

-- Assume my session time zone is 'America/New_York' SET TIME ZONE 'America/New_York'; -- Create a test table CREATE TABLE time_test ( ts_native TIMESTAMP, -- without tz ts_tz TIMESTAMPTZ -- with tz );

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. postgres timestamp vs timestamptz

If you have ever built an app that serves users across multiple time zones, you’ve likely woken up to a 3:00 AM page about "incorrect order dates" or "meetings showing up at the wrong hour." -- Assume my session time zone is 'America/New_York'

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 – . TIMESTAMPTZ does not save 'America/Chicago' or '+05:30'

To preserve the user's original time zone (e.g., for compliance or display), you need a :

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

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