Re: BUG #16216: the result of to_date function with negative yearnumber not same as BC year number
От | Fabien COELHO |
---|---|
Тема | Re: BUG #16216: the result of to_date function with negative yearnumber not same as BC year number |
Дата | |
Msg-id | alpine.DEB.2.21.2001171609210.31891@pseudo обсуждение исходный текст |
Ответ на | 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>) |
Ответы |
Re: BUG #16216: the result of to_date function with negative year number not same as BC year number
|
Список | 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 по дате отправления: