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

The following bug has been logged on the website:

Bug reference:      16216
Logged by:          zhongxuan sun
Email address:      szx9231@gmail.com
PostgreSQL version: 12.0
Operating system:   centos7
Description:

example:
postgres=# select to_date('-120', 'yyyy');
    to_date    
---------------
 0121-01-01 BC
(1 row)

postgres=# select to_date('120bc', 'yyyybc'); 
    to_date    
---------------
 0120-01-01 BC
(1 row)

I think -120 means 120bc, however, the output is 121bc not 120bc.

Thanks~

Hello,

> example:
> postgres=# select to_date('-120', 'yyyy');
>    to_date
> ---------------
> 0121-01-01 BC
> (1 row)
>
> postgres=# select to_date('120bc', 'yyyybc');
>    to_date
> ---------------
> 0120-01-01 BC
> (1 row)
>
> I think -120 means 120bc, however, the output is 121bc not 120bc.

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

Given that there are no year 0 (zero was invented much later), history 
skips form year -1 to year 1. If -120 means in the implementation "year as 
an integer", then skipping zero would mean that it indeed represents year 
121 BC, i.e. 120 years before "Jan 1, 1 AD". So there is a logic.

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'll try to have a look over the week-end.

-- 
Fabien.

Fabien COELHO <coelho@cri.ensmp.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

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

I agree.

> If we do anything about this, my vote would be to throw an error for 
> zero or negative year field.

Yep, being stricter.

> OTOH, the point of to_date is mostly not to throw an error, so maybe we 
> should leave it be.

I'll think about it.

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

Hmmm. Ok, I see.

If I write a fuzzy "31/12/01", I'm pretty okay with 2001-12-31. but if I 
write '1 AD', I would expect '1 AD'.

-- 
Fabien.

Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> 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.

> Hmmm. Ok, I see.

> If I write a fuzzy "31/12/01", I'm pretty okay with 2001-12-31. but if I 
> write '1 AD', I would expect '1 AD'.

Yeah, a case could be made for applying that rule only when there's
exactly two year digits.  OTOH, it's been like this for a very long
time with few complaints.  Besides, it'd still be weird when you
write "11 AD", so really people who are dealing with such dates
need to learn to write four year digits.

            regards, tom lane