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
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 |