Re: BUG #15351: to_date() function bug - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15351: to_date() function bug
Date
Msg-id 15477.1535126910@sss.pgh.pa.us
Whole thread Raw
In response to BUG #15351: to_date() function bug  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> All dates, that are less then '04.01.0001', returns in Before Christ (!)
> format.

Can't reproduce that here ...

> Examples:
> SELECT to_date('01.12.0000', 'DD.MM.YYYY'); - -   converts to 0001-12-01 BC
> (Before Christ)
> SELECT to_date('01.01.0000', 'DD.MM.YYYY'); - -   converts to 0001-01-01
> BC

Neither of the above are surprising.  There's no year zero in the
Gregorian calendar.  We could throw an error for that input, perhaps,
but what the code chooses to do is interpret it as 1BC.

> SELECT to_date('01.01.0001', 'DD.MM.YYYY'); - -   converts to 0001-01-01
> BC

That would be a bug, I agree, but I can't reproduce it here.  I get

regression=# SELECT to_date('01.01.0001', 'DD.MM.YYYY');
  to_date   
------------
 0001-01-01
(1 row)

and likewise for your other funny cases.  I wonder whether you're
using a stock build of Postgres --- or maybe you're running into
compiler bugs?  Where did you get PG from?

> SELECT  to_date('', 'DD.MM.YYYY'); - - empty text also converts to
> 0001-01-01 BC

That seems all right given the interpretation of zeroes.  There's probably
a market for a version of to_date that's more willing to throw errors for
questionable input ... but that's not how to_date itself has traditionally
worked.

            regards, tom lane


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15351: to_date() function bug
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #15344: pg_proc.proisagg was removed incompatibly inPostgreSQL 11