| 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
| 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 |