When the dateAdd algorithm is invoked by a dateTruncate function, it is requested to start from a reference date that is 2000-01-01, and add a number of days that for a year like 2020 is 7,300. Unfortunately timelib_add will end up adding the number of days to the current day and then call in a tight loop

void timelib_do_normalize(timelib_time* time)

..

	do {} while (do_range_limit_days(&time->y, &time->m, &time->d));

where each call will advance the date by 1 month at a time, removing the number of days of the current month from the overflowing number of days.
In a benchmark the difference can be seen by just changing the date that has to be reached with this slow advance rate:

--------------------------------------------------------------------------------------

Benchmark                                            Time             CPU   Iterations

--------------------------------------------------------------------------------------

BM_DateTruncEvaluateMonth6NewYorkValue2100       13469 ns        13184 ns        49778

BM_DateTruncEvaluateMonth6NewYorkValue2030        7301 ns         7394 ns       112000

Adding 70 years to the final date is responsible for an extra 6 ms us.

The algorithm could be improved on our side by preparing a timelib_rel_time argument in the getTimelibRelTime that would include a number of years plus a number of days (by converting 365 or 366 days into 1 year)