Re: BUG #19650: to_date()/to_timestamp() silently truncate 4+-digit day-of-year input to the first three digits

чт, 3 сент. 2026 г. в 18:02, PG Bug reporting form <noreply(at)postgresql(dot)org>:

> The following bug has been logged on the website:
>
> Bug reference: 19650
> Logged by: chunling qin
> Email address: 303677365(at)qq(dot)com
> PostgreSQL version: 18.6
> Operating system: x86_64
> Description:
>
> The documentation states that DDD (day of year) accepts values 001-366 and
> IDDD (ISO day of year) 001-371, and out-of-range values raise an error.
> That
> check works for 3-digit input, but for input of 4 or more digits the parser
> silently keeps only the first three digits and treats them as a valid day
> number:
>
> SELECT to_date('2024 1000', 'YYYY DDDD');
> -- 2024-04-09 (parsed as day 100 — the first three digits)
>
> SELECT to_date('2024 1234', 'YYYY DDDD');
> -- 2024-05-02 (parsed as day 123)
>
> SELECT to_date('2024 10000', 'YYYY DDDD');
> -- 2024-04-09 (5-digit input, still day 100)
>
> SELECT to_date('2024 999', 'IYYY IDDD');
> -- 2026-09-25 (IDDD 999 silently accepted; an ISO year has at most 371
> days)
>
> ```
> hunt@(null)=# SELECT to_date('2024 1000', 'YYYY DDDD');
> -- 2024-04-09 (parsed as day 100 — the first three digits)
>
> SELECT to_date('2024 1234', 'YYYY DDDD');
> -- 2024-05-02 (parsed as day 123)
>
> SELECT to_date('2024 10000', 'YYYY DDDD');
> -- 2024-04-09 (5-digit input, still day 100)
>
> SELECT to_date('2024 999', 'IYYY IDDD');
> -- 2026-09-25 (IDDD 999 silently accepted; an ISO year has at most 371
> days)
> to_date
> ------------
> 2024-04-09
> (1 row)
>
> to_date
> ------------
> 2024-05-02
> (1 row)
>
> to_date
> ------------
> 2024-04-09
> (1 row)
>
> to_date
> ------------
> 2026-09-25
> (1 row)
>
> hunt@(null)=# SELECT to_date('2024 367', 'YYYY DDD');
> -- ERROR: date/time field value out of range: "2024 367"
> ERROR: date/time field value out of range: "2024 367"
> ```
>
>
Hi!

Thanks for the report.

The holes are:

DDD / IDDD 001-366 / 001-371
SSSSS 0-86399
RM I-XII
IW 01-53 (WW 54+ already errored before; now checked
uniformly)
ID 1-7

YYYY DDDD parses as YYYY + DDD + weekday D. D is accepted but
ignored for date computation, so to_date('2024 1000', 'YYYY DDDD')
is not a DDD overflow case. to_date('2024 1000', 'YYYY DDD')
already failed, and still does.

The checks run when the field is parsed. A later 0 in TmFromChar
means the field was unset, so ID 0 and IW 0 cannot be rejected in
do_to_timestamp. SSSSS recovers a minus that was swallowed as a
separator, the same way TZH does. RM rejects a leftover roman
digit so XIII is not taken as XII.

Patch with regress in attachment.

--
Regards,
Rachitskiy Andrey