Re: BUG #16419: wrong parsing BC year in to_date() function

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #16419: wrong parsing BC year in to_date() function
Дата
Msg-id CAKFQuwba2CO2GVKiR351pwCwP0jk82+0GaG_sMcdYUWUbON3UQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16419: wrong parsing BC year in to_date() function  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы رد: BUG #16419: wrong parsing BC year in to_date() function
Список pgsql-bugs
On Wed, May 6, 2020 at 8:12 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
It does this seemingly by subtracting one from the year, making it positive, then (I infer) appending "BC" to the result.  Thus for the year "-1" it yields "0002-01-01 BC"


Specifically:


/*
 * There is no 0 AD.  Years go from 1 BC to 1 AD, so we make it
 * positive and map year == -1 to year zero, and shift all negative
 * years up one.  For interval years, we just return the year.
 */
#define ADJUST_YEAR(year, is_interval) ((is_interval) ? (year) : ((year) <= 0 ? -((year) - 1) : (year)))

The code comment took me a bit to process - seems like the following would be better (if its right - I don't know why interval is a pure no-op while non-interval normalizes to a positive integer).

Years go from 1 BC to 1 AD, so we adjust the year zero, and all negative years, by shifting them away one year,  We then return the positive value of the result because the caller tracks the BC/AD aspect of the year separately and only deals with positive year values coming out of this macro.  Intervals denote the distance away from 0 a year is so we can simply take the supplied value and return it.  Interval processing code expects a negative result for intervals going into BC.

David J.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #16419: wrong parsing BC year in to_date() function
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16420: problem running into post install step while installation.