Take into account: If the savings from choosing B are less than 1 full integer, it's NOT worth it YET to John.

Omg , 500 test cases. That is pretty nice problem. Indeed I thought that I will not pass random cases, but then it showed 11469.53ms .

The examples count amount of ways you can sum up to the value

My description excluding the examples even has sum in it.
It is pretty clear. The examples find how many values of n that exist. The commented out parts list out the consecutive integers.

I don't think the examples match the description as I understand it.

The examples count amount of ways you can sum up to the value
but the description I think suggests something else? maybe give "number of valid values of n" some name?
and I had to really stare at the examples to even guess what the solution is meant to do.

It's a good problem, but the description could be longer.

If the savings from choosing B are less than 1 full integer, it's NOT worth it YET to John

you actually never really round, only check "if I rounded now, will it be bigger?"
but the continue working with un-rounded values

Some cases I've gotten into went deep into 10000s of days. Take that into account.

The logic is sound. You're likely bumping into some edge cases where the ticket price falls too low to be properly counted.
Try printing out some logs while running the code, especially initial values.

Changing the decimal values datatype helped me in Java.
Apparently Float is TOO corect for the function this is being tested against.

    testing(Movie.movie(835076, 13, 0.97), 64270);

is an edge case which separates people who used doubles and didn't notice and people who tried float and rip out their hair

you need to convert to wanted doubles earlier (separate line), then do all the math on doubles.
then simple int(r) should work