From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 15:15:15 |
Message-ID: | alpine.DEB.2.21.2001171609210.31891@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-17 15:29:52 | Re: BUG #16216: the result of to_date function with negative year number not same as BC year number |
Previous Message | PG Bug reporting form | 2020-01-17 15:03:03 | BUG #16217: ECPG call interface && filename of the foo.pgc file for logging |