> Victor, is this issue still relevant given your recent work on time?

In Python 3.3, I modified time.time() to use GetSystemTimeAsFileTime() instead of gettimeofday().

In Python 3.5, I replaced _PyTime_gettimeofday(_PyTime_timeval *tp) (resolution of 1 us) with _PyTime_t _PyTime_GetSystemClock(void) (resolution of 1 ns).

Moreover, most Python functions now use internally a monotonic clock (_PyTime_GetMonotonicClock) instead of the system clock (_PyTime_GetSystemClock), especially to compute timeout. Python 3.5 now ensures that a monotonic clock is available, it checks once at runtime (during Python startup).

The initial issue "pytime.c loses precision under Windows" has been fixed in the issue #22117 which introduced the _PyTime_t type. The resolution of _PyTime_t is no more hardcoded in the API. Currently, it uses a resolution of 1 nanosecond, but it may be worse if we get compilation issues (no 64 bits signed integer type, too bad) or better (ex: if a compiler supports 128 bits signed integer type, I didn't try __int128 of GCC). The resolution is only handled in pytime.c, not in the users of the API.

> Martin: I think the best choice would be a decimal object--which, now that we have decimal in C, is probably sufficiently performant for serious consideration.

This change has been discussed in the PEP 410 which has been rejected.

datetime.datetime.now() now uses _PyTime_GetSystemClock() and so indirectly GetSystemTimeAsFileTime() on Windows. Since the datetime type may get nanosecond resolution (issue #15443), it will be possible to get the current time with nanosecond resolution ;-)

I now close the issue.