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.
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 – . postgres timestamp vs timestamptz
To preserve the user's original time zone (e.g., for compliance or display), you need a : Always use in your application code
Chances are, you chose the wrong PostgreSQL temporal data type. TIMESTAMPTZ does not save 'America/Chicago' or '+05:30'
-- Insert the same "local" value INSERT INTO time_test VALUES ('2025-04-14 14:00:00', '2025-04-14 14:00:00');
# Django/ORM example from django.utils import timezone import datetime bad_time = datetime.datetime(2025, 4, 14, 14, 0, 0) GOOD: Aware datetime good_time = timezone.now() # includes UTC offset