Re: BUG #16216: the result of to_date function with negative yearnumber not same as BC year number - Mailing list pgsql-bugs

From Fabien COELHO
Subject Re: BUG #16216: the result of to_date function with negative yearnumber not same as BC year number
Date
Msg-id alpine.DEB.2.21.2001171609210.31891@pseudo
Whole thread Raw
In response to Re: BUG #16216: the result of to_date function with negative year number not same as BC year number  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16216: the result of to_date function with negative year number not same as BC year number
List pgsql-bugs
>> 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.

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #16217: ECPG call interface && filename of the foo.pgc file for logging
Next
From: Tom Lane
Date:
Subject: Re: BUG #16216: the result of to_date function with negative year number not same as BC year number