Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment variable 'TZ' affects Unix.gettimeofday #6671

Closed
vicuna opened this issue Nov 22, 2014 · 3 comments
Closed

Environment variable 'TZ' affects Unix.gettimeofday #6671

vicuna opened this issue Nov 22, 2014 · 3 comments
Assignees
Milestone

Comments

@vicuna
Copy link

vicuna commented Nov 22, 2014

Original bug ID: 6671
Reporter: mdelahaye
Assigned to: @damiendoligez
Status: closed (set by @damiendoligez on 2015-03-25T00:50:26Z)
Resolution: fixed
Priority: normal
Severity: minor
OS: Windows
OS Version: MinGW & MSVC
Target version: 4.02.2+dev / +rc1
Fixed in version: 4.02.2+dev / +rc1
Category: platform support (windows, cross-compilation, etc)
Tags: github, patch
Monitored by: @gasche

Bug description

When 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 reproduce

Assuming 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

time=1416689426.000
gtod=1416693026.238

Instead of

time=1416689426.000
gtod=1416689426.238

Additional information

Why 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...

Regards
Mickaël

TZ and cygwin:
https://cygwin.com/ml/cygwin/2012-03/msg00048.html
Seconds to Epochs: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
Related issue: #5734

File attachments

@vicuna
Copy link
Author

vicuna commented Nov 23, 2014

Comment author: mdelahaye

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().

@vicuna
Copy link
Author

vicuna commented Dec 24, 2014

Comment author: @damiendoligez

see #122: #122

@vicuna
Copy link
Author

vicuna commented Mar 25, 2015

Comment author: @damiendoligez

Fixed in 4.02 branch (rev 15958).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants