Re: BUG #16216: the result of to_date function with negative year number not same as BC year number

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: szx9231(at)gmail(dot)com, PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16216: the result of to_date function with negative year number not same as BC year number
Date: 2020-01-17 14:59:42
Message-ID: 26771.1579273182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> postgres=# select to_date('-120', 'yyyy');
>> to_date
>> ---------------
>> 0121-01-01 BC
>> (1 row)

> ISTM that the documentation does not say that -120 is supported as meaning
> BC.

Indeed it does not. The behavior is "correct" in terms of our internals,
as you say, but I'm a bit distressed to find that we're exposing the
internals this much. If we do anything about this, my vote would be
to throw an error for zero or negative year field. OTOH, the point of
to_date is mostly not to throw an error, so maybe we should leave it be.

> BTW I found another oddity while trying strange date patterns:
> sql> SELECT DATE 'Jan 1, 0001 AD';
> # 0001-01-01
> But:
> sql> SELECT DATE 'Jan 1, 1 AD';
> # 2001-01-01 # WT*?

I'm pretty sure that's intentional; if you specify two or fewer
year digits, a year between 1970 and 2069 is presumed to be meant.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-01-17 15:03:03 BUG #16217: ECPG call interface && filename of the foo.pgc file for logging
Previous Message Fabien COELHO 2020-01-17 14:17:34 Re: BUG #16216: the result of to_date function with negative year number not same as BC year number