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

On Wed, May 6, 2020 at 8:12 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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:

https://github.com/postgres/postgres/blob/fb544735f11480a697fcab791c058adc166be1fa/src/backend/utils/adt/formatting.c#L236

/*
* 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.