That's good to know, thanks! :)

(I know that the suggestion is 6 years old, but I want to add a small not-so-serious explanation for the kata task)

Actually, the procentual loss doesn't seem too far fetched. The loss could be because the evaporator is not sealed perfectly air-tight (alright, alright, then a "gas-container" would be a better example than an evaporator) and at day n we try to use it for the first time and want to know if there's still enough deodorant left to be worth it.

Alternatively, the total amount of gas in the evaporator could stay the same while just the ratio of deodorant to normal air decreases. This way, we use the same amount of gas every morning with an decreasing amount of actual deodorant, in which case, indeed, stinking greetz! :D

You have to always round up. There are two ways to argue about this (because the task is not fully clear about how to interpret the time):

• The logarithm can give you a result like 28.3, in which case the deodorant will fail at some point between the beginning of day 28 and day 29. In that case we would say that it fails on day 29, since it still works at the beginning of day 28.
• To be more precise, the first day starts at time t=0 and ends at t=1, because we say that at the time t=1 we already have the loss of a whole day. Therefore, it's more correct to say that day 29 starts at t=28 and ends at t=29. With this, the deodorant fails at 28.3, during day 29.

Anyways, just look up how to round up numbers in your language of choice. :)

I recommend returning and testing the result as a string. I tried different solutions that gave me errors like

Expected: 2.65, instead got: 2.65

even after rounding at the end, probably because slight differences in the way I rounded as compared to the test. With string comparison such errors cannot occur.

Better remove the line fesetround(FE_UPWARD).

The solution should work without this and with this line the rounding method is changed for the rest of the program as well after calling centuryFromYear, which is probably an unwanted side-effect. In bigger projects, it is easy to forget such a side effect and to stumble over strange bugs.
Otherwise a nice solution. :)

That would also make it possible to easily check if <= is used instead of < by doing a test with epsilon=0. (Assuming that the authors want to integrate this as a condition to pass the kata)

I assume that in the task description the authors just use the word float for floating point values (float, double) in differentiation to integer values (for int, unsigned int, long, ...). If the values being compared are actually meant to be of the concrete type float insted of double, then I would also prefer using float as function arguments, since using double doesn't add any precision benefits in this case.

Without knowing the exact context of the language and kata you're talking about it's hard to say for sure, but it does make sense since print() and return should have different features.
print() prints the output to console (so that we as the user can read it) while return actually returns the value to whereever the function was called. E.g. the function
int multiply (int a, int b ){...} (in C++)
should use return so that in other places of your program you can use statements like
c = multiply( a, b );
and c will actually be assigned the value a times b. If you used print() inside the function, then that value would just be printed but not assigned to c. The test cases most likely check for the return value of the function, so print() does not fulfill the test conditions.