| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: to_date()/to_timestamp() silently accept month=0 and day=0 |
| Date: | 2026-04-23 15:40:14 |
| Message-ID: | 1444609.1776958814@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 23 Apr 2026, at 09:57, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Perhaps we could consider strengthening such inputs on HEAD once v20
>> opens for business? It would be really a scary thing to backpatch,
>> still a major release is a different thing.
> This could definitely not be backpatched IMO, a quick check in v14 shows the
> same behaviour. The gregorian calendar goes from BC1 to AD1 and does not
> define a year 0, to_date('0000','YYYY') correctly returns year 0001, handling
> months/days in the same way at least makes it consistent (though I didn't scour
> the archives to see if it was intentionally done like that).
Looking at the code, I think it intentionally interprets zero as
"missing data". See for example the stanza at formatting.c:4650ff
where tm_mon and tm_mday can be backfilled from a DDD field.
I'm disinclined to change the behavior around this; you're far
more likely to get complaints than kudos.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-04-23 16:36:41 | Re: to_date()/to_timestamp() silently accept month=0 and day=0 |
| Previous Message | Владимир Фролов | 2026-04-23 15:17:32 | pg_dumpall bug exit code 0 with fatal |