Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006671OCamlplatform support (windows, cross-compilation, etc)public2014-11-22 23:452015-11-29 15:05
Assigned Todoligez 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSWindowsOS VersionMinGW & MSVC
Product Version 
Target Version4.02.2+dev / +rc1Fixed in Version4.02.2+dev / +rc1 
Summary0006671: Environment variable 'TZ' affects Unix.gettimeofday
DescriptionWhen running some experiments with timing functions on Windows, I ran into a problem that occurred only in Cygwin's Bash: gettimeofday provided non-UTC timestamps. After some code inspection, here and there, I found the culprit: the TZ environment variable affects gettimeofday and it shouldn't.

Unix.gettimeofday under Windows (mingw and msvc) uses C's 'mktime' to convert a Windows-specific local time (provided by 'GetLocalTime') to a Unix timestamp. However 'mktime' (here Microsoft's one in msvcrt) is sensible to the TZ environment variable. All would be well if 'GetLocalTime' would also take TZ into account. But obviously it does not. Consequently, a wrong time offset appears if TZ is set and is not the current local time zone of Windows.

A possible patch is provided (more information below).
Steps To ReproduceAssuming you don't live in the GMT timezone, run this program with a setting TZ to "" (for instance):

let () = Printf.printf "time=%.3f\ngtod=%.3f\n" (Unix.time ()) (Unix.gettimeofday ())

It may return something like that


Instead of

Additional InformationWhy does it appears inside a Cygwin shell? TZ as some legitimate uses in Cygwin. And Cygwin defines by default TZ to the current time zone of the system (Europe/Paris for me). In this particular case, it should be good, no? obviously not! Microsoft and Cygwin do not have the same understanding of what is a good TZ value.

One possible solution is to not use 'mktime' (patch provided).
Note that the C standard library does not a UTC equivalent of 'mktime', so my patch just uses the Open Group's definition of the seconds to Epochs. It is not perfect, i.e. it ignores possible time shifts (leap seconds and co). In practice, it does work and Unix.gettimeofday does sync beautifully with Unix.time (modulo the milliseconds). It makes me believe that msvcrt's implementation of mktime is as naive as my implementation ;)

However, as you may have noticed from the get-go, this problem is not so current, likely, because the main use of gettimeofday is to measure time periods and beautifully cancels any inappropriate time offset. And because a simple workaround exists (unsetting any TZ before calling an OCaml program), my patch might not be worth its future cost in maintenance and well possibly debugging. However, if you have other ideas...


TZ and cygwin: [^]
Seconds to Epochs: [^]
Related issue: 0005734
Tagsgithub, patch
Attached Filespatch file icon 0001-Remove-mktime-from-gettimeofday-fix-TZ-issue.patch [^] (2,286 bytes) 2014-11-22 23:45 [Show Content]
patch file icon 0001-Fix-TZ-issue-in-gettimeofday.patch [^] (1,853 bytes) 2014-11-23 13:57 [Show Content]

- Relationships

-  Notes
mdelahaye (reporter)
2014-11-23 14:00

Better patch that let Microsoft do the arithmetic ;)
Get a Windows timestamp (start at January 1, 1601) and shift it to a Unix timestamp. Does not take into account any time shift, but Windows does not either in any of its time primitives. So it's consistent with msvcrt's standard library time().
doligez (administrator)
2014-12-24 17:31

see GPR#122: [^]
doligez (administrator)
2015-03-25 01:50

Fixed in 4.02 branch (rev 15958).

- Issue History
Date Modified Username Field Change
2014-11-22 23:45 mdelahaye New Issue
2014-11-22 23:45 mdelahaye File Added: 0001-Remove-mktime-from-gettimeofday-fix-TZ-issue.patch
2014-11-23 13:57 mdelahaye File Added: 0001-Fix-TZ-issue-in-gettimeofday.patch
2014-11-23 14:00 mdelahaye Note Added: 0012564
2014-12-24 17:29 doligez Tag Attached: patch
2014-12-24 17:30 doligez Tag Attached: github
2014-12-24 17:31 doligez Note Added: 0012984
2014-12-24 17:31 doligez Status new => acknowledged
2015-01-13 22:12 doligez Target Version => 4.02.2+dev / +rc1
2015-03-24 21:56 doligez Assigned To => doligez
2015-03-24 21:56 doligez Status acknowledged => assigned
2015-03-25 01:50 doligez Note Added: 0013539
2015-03-25 01:50 doligez Status assigned => closed
2015-03-25 01:50 doligez Resolution open => fixed
2015-03-25 01:50 doligez Fixed in Version => 4.02.2+dev / +rc1
2015-11-29 15:05 xleroy Relationship added related to 0004466
2015-11-29 15:05 xleroy Relationship deleted related to 0004466
2017-02-23 16:46 doligez Category OCaml windows => platform support (windows, etc)
2017-02-23 17:16 doligez Category platform support (windows, etc) => platform support (windows, cross-compilation, etc)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker