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

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.

In response to

Responses

Browse pgsql-bugs by date

  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