Re: BUG #15351: to_date() function bug

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15351: to_date() function bug
Дата
Msg-id 15477.1535126910@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #15351: to_date() function bug  (PG Bug reporting form <noreply@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15351: to_date() function bug
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #15344: pg_proc.proisagg was removed incompatibly inPostgreSQL 11