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

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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 08:26:01
Message-ID: CAJTYsWVf7wPE9YWL5Bf310KzWPJiQ9JiW8rT_wtjSiLtAzBCGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Thu, 23 Apr 2026 at 13:41, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:

> > 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).
>
>
++ on not backporting it since it may break existing applications.

But we should consider strengthening such inputs for v20.

Regards,
Ayush

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tender Wang 2026-04-23 08:26:48 Re: BUG #19435: Error: "No relation entry for relid 2" Triggered by Complex Join with Self-Referencing Tables
Previous Message Daniel Gustafsson 2026-04-23 08:11:47 Re: to_date()/to_timestamp() silently accept month=0 and day=0