Incident brief
Invalid datetime format
A text value was cast to a date/time type, but PostgreSQL couldn't parse it as any recognized date/time format at all.
What lands in your log
ERROR: invalid input syntax for type date: "not-a-real-date"
In 10 seconds
- What triggers it
- Cast plain, unparseable text to date.
- Fix
- Send dates in ISO 8601 format (YYYY-MM-DD), the manual's own recommended, unambiguous format.
- Proof
- Reproduced on PostgreSQL 16.14 → Casting plain garbage text to date was rejected with SQLSTATE 22007. The session was unaffected afterward.
Fix
What to do right now
Application-level steps for this error.
- Send dates in ISO 8601 format (YYYY-MM-DD), the manual's own recommended, unambiguous format.
- Validate the string is even shaped like a date in application code before sending it to PostgreSQL.
- Don't confuse this with 22008, see the premium test for the difference between 'unreadable' and 'reads fine but doesn't exist'.
SELECT '1999-01-08'::date;For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Invalid datetime format (22007) 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.
Validate the bound timestamp under the session settings
Validate the specific value/shape that can raise this SQLSTATE.
SHOW DateStyle;
SHOW TimeZone;
-- Then test the exact bound literal explicitly:
-- SELECT <timestamp_literal>::timestamptz;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, Date/Time Types, Table 8.10
1999-01-08, ISO 8601; January 8 in any mode (recommended format)Read the full section on postgresql.org →
The unparseable cast
"not-a-real-date" doesn't match any date format PostgreSQL recognizes, per the manual's own list of accepted date inputs, so it's rejected before PostgreSQL can even ask whether the date itself makes sense.Confirming the session still works
The unparseable date string was rejected before PostgreSQL touched any row, so session B's next statement proceeds as normal.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.
- 1Cast plain, unparseable text to date.
- 2PostgreSQL cannot recognize the text as any date format it knows.
- 3SQLSTATE 22007 is reported.
One client: cast a string PostgreSQL can't parse as any date format.
-- No table needed: the failure happens purely at the type-cast stage.
SELECT 'no schema required' AS setup_note;SELECT 'not-a-real-date'::date;SELECT 1 AS session_still_alive;What PostgreSQL actually returned
setup_note
--------------------
no schema required
(1 row)ERROR: invalid input syntax for type date: "not-a-real-date"
LINE 1: SELECT 'not-a-real-date'::date;
^ session_still_alive
----------------------
1
(1 row)22007 and 22008 sound similar but are different codes for different problems. This was tested directly: the same style of date cast, but with text that PostgreSQL CAN parse, on a day that doesn't exist on the calendar.
Without this
Above: text PostgreSQL can't parse at all is rejected with SQLSTATE 22007.
With this, tested
Below: text PostgreSQL CAN parse, but names a day that doesn't exist, is rejected with a DIFFERENT SQLSTATE, 22008.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- A measured datestyle before/after
- A manual-grounded production interpretation of the lab result
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-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 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.