I think this issue can be resolved by reducing the loss to the maximum available precision; it's about time.time(), after all.

I don't think pygettimeofday can change; gettimeofday traditionally has only µs. So the issue really is that it is used in implementing time.time().

As for whether an integer-returning current-time function in Python is needed: -1 (but then, I voiced the same concern when the ns-filestamp APIs where added). Adding an API will "force" people to rewrite their code, with no real improvement for practical improvement. The "force" comes from the mere availability of the API, and any emerging claims that using the time_ns() function is "more correct".

I really wish Python would have a 128-bit floating point type that could be used to represent a time stamp. Until such a type is available (perhaps in 2025), I propose that we live with limitations of 64-bit floating point. Anybody *really* needing the Windows system time can use ctypes (or pywin32) already.