Please don't open an issue when you're not sure if the problem is in your code. The hint I can give you: check your data types. And two posts below yours, someone wrote exactly that.

It is because by use of float and real division operator /, you introduce small inaccuracies into your solution, which sometimes, in certain circumstances, for some inputs, can trick your solution into doing some incorrect approximation, or unintended rounding, because this is how floats work. When you change line 6 of your solution to something like time_decimal_secs = g * 60 * 60 // relative_speed, you have no floats anymore, no inaccuracies, and (if I see correctly) solution with this change will always pass.

You can check what exactly happens by recreating one of failing inputs in your IDE and running it with a step-through debugger, observing intermediate variables. You will notice how in some point, some rounding happens, which slightly changes the outcome and leads to an incorrect answer.

It's not about tests which are "rounded up". It's about your code which is a bit buggy, and sometimes performs incorrect rounding.

Your solution has a bug and it will not work in pycharm if you run it more than once.

Bugs in your solution are not a kata issue.

OP solved it, closing

That's because when you do "ab#".replace("#", "\b"), you get "ab\b" as a result, and not "a". And when you print the "ab\b" to the screen, it may (but does not have to) look like just a.
So basically what you print looks like a, but in reality it is "ab\b" (three characters), which is not equal to "a".

I do honestly doubt it works in PyCharm.
What does this code print in PyCharm?
print('ab#'.replace('#', '\b') == 'a')

Use print(a, b) the log shows above the test result. Why are you marking this as a kata issue?

There are no rrors in the tests.