PostgreSQL throws datetime field overflow (SQLSTATE 22008) when a date or time value is outside the valid range for its field. Common causes include invalid dates like "0000-00-00 00:00:00", incorrect formats, or timestamps with excessive precision.
PostgreSQL enforces strict validation on date and time values to maintain data integrity. When you attempt to insert, update, or convert a date/time value that falls outside the valid range for that field, PostgreSQL raises error 22008 (datetime_field_overflow). This differs from some other databases that might coerce invalid dates forward—PostgreSQL simply rejects them. Valid DATE values range from 4713 BC to 5874897 AD, but common issues occur with impossible dates like month 13, day 32, or February 29 on non-leap years.
Check your application logs to find the exact query causing the error. Note which column is referenced in the error message.
Example error:
ERROR: date/time field value out of range: "0000-00-00 00:00:00"Examine the actual data being inserted or the SQL query. Look for:
- Zero dates: "0000-00-00 00:00:00"
- Invalid components: month > 12, day > 31
- February 29 on non-leap years
- Timestamps in milliseconds or nanoseconds
Example problem query:
INSERT INTO users (created_at) VALUES ('0000-00-00 00:00:00');Replace "0000-00-00 00:00:00" with NULL for empty timestamp fields. PostgreSQL requires NULL for missing values.
Before:
INSERT INTO users (created_at) VALUES ('0000-00-00 00:00:00');After:
INSERT INTO users (created_at) VALUES (NULL);In your application code:
const createdAt = dateValue === '0000-00-00 00:00:00' ? null : dateValue;If inserting Unix timestamps (seconds or milliseconds since epoch), convert them to PostgreSQL timestamp format first.
For Unix timestamp in seconds:
SELECT to_timestamp(1678513615);
-- Returns: 2023-03-11 09:06:55+00:00For Unix timestamp in milliseconds, divide by 1000:
SELECT to_timestamp(1678513615000 / 1000.0);In your ORM or application:
const timestamp = new Date(unixTimestampMs);
const pgFormat = timestamp.toISOString(); // '2023-03-11T09:06:55.000Z'PostgreSQL uses YYYY-MM-DD format for dates. Validate before inserting:
- Year: any reasonable value (4713 BC to 5874897 AD)
- Month: 1-12
- Day: 1-31 (depending on month)
- Hour: 0-23
- Minute/Second: 0-59
Example validation in JavaScript:
const date = new Date('2024-02-30'); // Invalid
if (!Number.isNaN(date.getTime())) {
// Date is valid
} else {
// Handle invalid date
}In SQL, check leap years for February 29:
SELECT '2024-02-29'::date; -- Valid (2024 is leap year)
SELECT '2023-02-29'::date; -- ERROR (2023 is not leap year)PostgreSQL interprets ambiguous dates based on the datestyle setting. Check current setting:
SHOW datestyle;
-- Returns: ISO, MDY (or similar)If dates are being misinterpreted, adjust the setting:
SET datestyle = 'ISO, MDY';
-- or
SET datestyle = 'ISO, DMY';For permanent change, update postgresql.conf or use in connection string:
PostgreSQL://user:pass@host/db?options=-c%20datestyle%3DISO,MDYAlways use ISO format (YYYY-MM-DD) in applications to avoid ambiguity.
PostgreSQL stores timestamps as 8-byte integers (since version 8.4), measuring microseconds since epoch. This limits the valid range to approximately 4713 BC to 5874897 AD. Unlike MySQL, which coerces invalid dates to zero dates or rounds them forward, PostgreSQL strictly validates dates on insert/update. When migrating from MySQL, systematically replace "0000-00-00 00:00:00" values with NULL. For timezone-aware applications, use TIMESTAMP WITH TIME ZONE. Always validate dates at the application layer before hitting the database to provide better error messages to users. If debugging corrupted timestamps in existing data, use binary-level queries to identify timestamps falling outside valid ranges.
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL
Bind message supplies N parameters but prepared statement requires M
Bind message supplies N parameters but prepared statement requires M in PostgreSQL
Multidimensional arrays must have sub-arrays with matching dimensions
Multidimensional arrays must have sub-arrays with matching dimensions
ERROR: value too long for type character varying
Value too long for type character varying
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL