You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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: