asyncio.BaseEventLoop _clock_resolution has no effect about cpython

[zware]

Note that the loop uses time.monotonic(), not time.time(), so time since the Unix epoch is irrelevant here. time.monotonic() does not have a defined reference point (it's generally probably related to system uptime, but no guarantees). My personal system currently gives something around 192187.52431901, which is happily affected by adding 1e-09.

I don't think there's a real bug here; the likelihood of a time.monotonic() timestamp getting big enough to cause this kind of problem seems remote. It might still be a good idea to migrate to time.monotonic_ns() just to make the issue impossible, but that's going to take some serious consideration in all time-related asyncio APIs to avoid breaking things with the change.

[KholdStare]

Some thoughts I had - ideally timestamps would be 64bit ints with nanosecond precision - then the above calculation would work out. However, since we are dealing with 64bit floats, there's only 53 bits of precision. Perhaps when _clock_resolution is stored in the event loop, it should be "bumped up" to the smallest increment that would not lead to precision loss. I.e. a floating point with the same exponent as a typical epoch time, but the mantissa being 1.

[KholdStare]

Thank you for the quick response. This makes sense to me. Feel free to close the issue. Would a comment be useful in the code to warn of this behavior? I'm not sure if there is an environment out there where the monotonic clock acts as epoch time - but if there is, then this issue would apply.