Re: to_date()/to_timestamp() silently accept month=0 and day=0

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

In response to

Responses

Browse pgsql-bugs by date

  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