Unix.gettimeofday correct resolution under Windows #5734
Original bug ID: 5734
Current implementation of Unix.gettimeofday is not accurate as it is initialised with a time source with a resolution in seconds.
Steps to reproduce
First call to Unix.gettimeofday under Windows always returns a time rounded to the nearest number of seconds.
The attached patch uses the Win32 API GetLocalTime (not GetSystemTime as the result is used to pass a struct to mktime) which returns the current time to the nearest millisecond. This is used to initialise initial_time in gettimeofday.c
Patch was made against 3.12.1, but the file is unchanged in trunk. Patch respects m.h's definition of HAS_MKTIME but this is redundant under Windows as it always does have MKTIME.
Note that using GetTickCount means that Unix.gettimeofday never responds to the local clock being corrected forwards. For long lived processes this could be a problem? GetTickCount is recommended for measuring elapsed time - shouldn't Unix.gettimeofday always query the local clock?
The text was updated successfully, but these errors were encountered: