Re: BUG #16419: wrong parsing BC year in to_date() function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16419: wrong parsing BC year in to_date() function
Date: 2020-09-29 18:18:58
Message-ID: 712970.1601403538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I wrote:
> I think this is nuts. The current behavior is obviously broken;
> we should just treat it as a bug and fix it, including back-patching.
> I do not think there is a compatibility problem of any significance.
> Who out there is going to have an application that is relying on the
> ability to insert BC dates in this way?

Concretely, I propose the attached. This adjusts Dar Alathar-Yemen's
patch (it didn't do the right thing IMO for the combination of bc
and year < 0) and adds test cases and docs.

Oracle would have us throw an error for year zero, but our historical
behavior has been to read it as 1 BC. That's not so obviously wrong
that I'd want to change it in the back branches. Maybe it could be
done as a follow-up change in HEAD.

regards, tom lane

Attachment Content-Type Size
fix-to-date-for-negative-years.patch text/x-diff 4.1 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Nagaraj Raj 2020-09-29 18:22:50 Re: recovery.conf' is not creating in pg_basebackup with version 13
Previous Message Nagaraj Raj 2020-09-29 18:18:25 Re: table partition with inheritance having current_timestamp issue if we miss range table

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2020-09-29 18:33:42 Re: BLOB / CLOB support in PostgreSQL
Previous Message Andrey M. Borodin 2020-09-29 18:04:18 Re: Yet another fast GiST build