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

On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote:
> On Tue, May 12, 2020 at 8:56 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> 
>     On Tue, 2020-05-12 at 18:09 -0700, David G. Johnston wrote:
>     > Redirecting to -hackers for visibility.  I feel there needs to be
>     something done here, even if just documentation (a bullet in the usage
>     notes section - and a code comment update for the macro)
>     > pointing this out and not changing any behavior.
> 
>     Since "to_date" is an Oracle compatibility function, here is what Oracle
>     18.4 has to say to that:
> 
>     SQL> SELECT to_date('0000', 'YYYY') FROM dual;
>     SELECT to_date('0000', 'YYYY') FROM dual
>                    *
>     ERROR at line 1:
>     ORA-01841: (full) year must be between -4713 and +9999, and not be 0
> 
> 
> 
> Attached is a concrete patch (back-patchable hopefully) documenting the current
> reality.
> 
> As noted in the patch commit message (commentary really):
> 
> make_timestamp not agreeing with make_date on how to handle negative years
> should probably just be fixed - but that is for someone else to handle.
> 
> Whether to actually change the behavior of to_date is up for debate though I
> would presume it would not be back-patched.

OK, so, looking at this thread, we have to_date() treating -1 as -2 BC,
make_date() treating -1 as 1 BC, and we have Oracle, which to_date() is
supposed to match, making -1 as 1 BC.

Because we already have the to_date/make_date inconsistency, and the -1
to -2 BC mapping is confusing, and doesn't match Oracle, I think the
clean solution is to change PG 14 to treat -1 as 1 BC, and document the
incompatibility in the release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee