Incident brief
Time zone displacement out of range
A timestamptz literal whose explicit UTC offset lies outside the valid range (about -15:59 to +15:59) raises this data exception; +16:00 is out of range.
What lands in your log
ERROR: time zone displacement out of range: "2026-01-01 12:00:00+16:00"
In 10 seconds
- What triggers it
- Write a TIMESTAMP WITH TIME ZONE literal with an explicit offset beyond the allowed range, such as +16:00.
- Fix
- Use a valid UTC offset (within about +/-15:59).
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 22009; the +16:00 displacement is rejected while the literal is parsed.
Fix
What to do right now
Application-level steps for this error.
- Use a valid UTC offset (within about +/-15:59).
- Fix the source data or the offset generator so displacements stay in range; the server stores in UTC and renders in the session zone.
-- Use a UTC offset within the valid range.
SELECT TIMESTAMP WITH TIME ZONE '2026-01-01 12:00:00+02:00';For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Time zone displacement out of range (22009) is statement-local: PostgreSQL does not retain the rejected value after the statement ends. Capture the exact bound value and statement position in application/server logs, then run this targeted validation before retrying.
Check timezone settings and offset range
Validate the specific value/shape that can raise this SQLSTATE.
SHOW TimeZone;
SELECT offset_hours,
abs(offset_hours) > 15 AS suspicious_offset
FROM (VALUES (16)) v(offset_hours);Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 18 Documentation, Appendix A. PostgreSQL Error Codes (Table A.1, Class 22, Data Exception)
22009 → invalid_time_zone_displacement_valueRead the full section on postgresql.org →
Supplying an out-of-range UTC offset
Valid time-zone displacements span roughly -15:59 to +15:59, so +16:00 raises 'time zone displacement out of range'.The session continues normally
The time-zone check failed outside a transaction block, leaving the session free to run its next statement without a ROLLBACK.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Write a TIMESTAMP WITH TIME ZONE literal with an explicit offset beyond the allowed range, such as +16:00.
- 2PostgreSQL parses the literal and validates the time-zone displacement.
- 3An out-of-range offset aborts the statement with SQLSTATE 22009.
A feed supplied timestamps with a malformed offset (+16:00), and every affected row failed to cast to timestamptz.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT TIMESTAMP WITH TIME ZONE '2026-01-01 12:00:00+16:00';SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: time zone displacement out of range: "2026-01-01 12:00:00+16:00"
LINE 1: SELECT TIMESTAMP WITH TIME ZONE '2026-01-01 12:00:00+16:00';
^ session_after_error
---------------------
ok
(1 row)The same timestamp parses once the offset is within range.
Without this
Before: +16:00 is out of range
With this, tested
After: +02:00 parses and normalizes
- A second operational test: exact SQL, raw output, measured result, and engineer notes
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-24 (isolated lab, PostgreSQL 18.4)
- Verification scope
- Verified against PostgreSQL 18.4 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.