agora inbox for pgsql-bugs@postgresql.org  

help / color / mirror / Atom feed

From: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: malis@pgrust.com
Subject: BUG #19590: to_date/to_timestamp "Y,YYY" accepts out-of-range values
Date: Fri, 31 Jul 2026 05:57:01 +0000
Message-ID: <19590-991c467c2a601be0@postgresql.org> (raw)

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.

view thread (2+ messages)  latest in thread

Message-ID: <19590-991c467c2a601be0@postgresql.org>
Permalink:  ../19590-991c467c2a601be0@postgresql.org/
Also on:    postgresql.org/message-id/19590-991c467c2a601be0@postgresql.org

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: noreply@postgresql.org, pgsql-bugs@lists.postgresql.org, malis@pgrust.com
  Subject: Re: BUG #19590: to_date/to_timestamp "Y,YYY" accepts out-of-range values
  In-Reply-To: <19590-991c467c2a601be0@postgresql.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox