I think this isn't the case for asyncio, it is uvloop which incorrectly calls the callback early right?

It is according to asveltov.
By adding that guarantee, we will also require it from different implementations, whether different Python or different drop-in replacement packages.

we will also require it from different implementations, whether different Python or different drop-in replacement packages.

Yes, for an API like call_later it is fine if the callback gets delayed one extra cycle because of floating point/ timer resolution error but it should definitely not call it earlier.

This is ensured in asyncio by end_time = self.time() + self._clock_resolution

To be clear uvloop is at fault here and that should be fixed but we should document the correct behavior here not what happens with uvloop.

So yeah, the documentation says exactly that - they may run up to one clock-resolution early, which is both the asyncio and expected behavior.

Yes, for an API like call_later it is fine if the callback gets delayed one extra cycle because of floating point/ timer resolution error but it should definitely not call it earlier.

This is ensured in asyncio by end_time = self.time() + self._clock_resolution

I think you got confused a little - asyncio does call it earlier - up to one clock resolution. The end_time = self.time() + self._clock_resolution is what asyncio handles. Callbacks scheduled after the current self.time() will still run as long as they are less than end_time.

Ah, got it, I had misinterpreted the issue.

Anyways, the docs seems fine then, I would appreciate @asvetlov to have a look as well.