Unix.gettimeofday correct resolution under Windows #5734
Labels
Milestone
Comments
|
Comment author: @xavierleroy Thanks for the patch. It's merged in trunk (r12949), will be part of the next major release (4.01). For the record, the original code probably predates the introduction of GetLocalTime in the Win32 API at the time of Win2000. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Original bug ID: 5734
Reporter: @dra27
Status: closed (set by @xavierleroy on 2015-12-11T18:08:08Z)
Resolution: fixed
Priority: normal
Severity: tweak
Version: 3.12.1
Target version: 4.01.0+dev
Fixed in version: 4.01.0+dev
Category: platform support (windows, cross-compilation, etc)
Bug description
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.
Additional information
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?
File attachments
The text was updated successfully, but these errors were encountered: