Re: BUG #15351: to_date() function bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: infinite77derger(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15351: to_date() function bug
Date: 2018-08-24 16:08:30
Message-ID: 15477.1535126910@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2018-08-24 19:53:44 Re: BUG #15344: pg_proc.proisagg was removed incompatibly in PostgreSQL 11
Previous Message PG Bug reporting form 2018-08-24 15:42:43 BUG #15351: to_date() function bug