BUG #19590: to_date/to_timestamp "Y,YYY" accepts out-of-range values

Hi, Michael!

Thanks for report.

DCH_Y_YYY used to parse millennia with sscanf("%d"). That silently
truncates values outside int range, so
```
SELECT to_date('4294969320,024', 'Y,YYY'); -- 2^32+2024
SELECT to_date('-4294965272,024', 'Y,YYY');
```
used to return 2024024-01-01 instead of erroring.

Other numeric fields already reject this via
from_char_parse_int_len(); the pg_mul_s32_overflow() check in
DCH_Y_YYY runs too late, after %d has discarded the magnitude.

This patch replaces the millennia %d with a single strtol(), using
the same ERANGE / INT_MIN / INT_MAX checks as from_char_parse_int_len().
The years part remains sscanf("%03d"): the field width limits the
conversion to three characters, so the value always fits in int. The
existing mul/add overflow checks are unchanged (they still catch
cases like 1000000000,999).

Y,YYY has two pieces: variable-width millennia up to a comma, then
three year digits. We parse and validate each separately.

Patch with tests, attached.

пт, 31 июл. 2026 г. в 14:47, PG Bug reporting form <noreply@postgresql.org>:

The following bug has been logged on the website:

Bug reference: 19590
Logged by: Michael Malis
Email address: malis@pgrust.com
PostgreSQL version: 18.4
Operating system: Debian 18.4-1.pgdg13+1, aarch64
Description:

The Y,YYY template field parses its millennia component with a bare
sscanf(..., "%d", ...), which silently truncates values too large for int
instead of rejecting them, so out-of-range input yields a wrong year:

SELECT to_date('4294969320,024','Y,YYY'); -- 2024024-01-01 (expected:
error)
SELECT to_date('-4294965272,024','Y,YYY'); -- 2024024-01-01 (expected:
error)

4294969320 is 2^32 + 2024, so it truncates to 2024 and is read as 2024
millennia; any multiple of 2^32 works, and %d accepts a sign, so wrapped
negatives too. to_timestamp() shares the code path. Every other numeric
field rejects this:

SELECT to_date('4294969320','YYYY');
-- ERROR: value for "YYYY" in source string is out of range

Cause: DCH_Y_YYY is the only numeric field using raw sscanf; the others go
through from_char_parse_int_len(), which range-checks with strtol/ERANGE.
The existing pg_mul_s32_overflow guard in DCH_Y_YYY runs too late. %d has
already discarded the magnitude.

Suggested fix: after the sscanf, re-scan the millennia field with strtol
and
reject ERANGE or out-of-int-range values, matching
from_char_parse_int_len():

errno = 0;
lval = strtol(s, &endptr, 10);
if (errno == ERANGE || lval < INT_MIN || lval > INT_MAX)
ereturn(escontext,,
(errcode(ERRCODE_DATETIME_FIELD_OVERFLOW),
errmsg("value for \"%s\" in source string is out of range",
"Y,YYY"),
errdetail("Value must be in the range %d to %d.", INT_MIN,
INT_MAX)));

strtol skips leading whitespace and stops at the comma exactly as %d does,
so this only adds a rejection path; the ERANGE test covers 32-bit-long
platforms where strtol saturates.

--
Regards,
Rachitskiy Andrey