Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006215OCamlOCaml otherlibspublic2013-10-29 17:182013-11-04 12:59
Reporterdaweil 
Assigned Toprotz 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionno change required 
PlatformmingwOSWindowsOS Version
Product Version4.01.0 
Target VersionFixed in Version 
Summary0006215: Unix.mktime fails or is incorrect on Windows
DescriptionFunction Unix.mktime fails in windows for time <= 3599 seconds
and is incorrect for time > 3600. seconds.

note that it works fine in a cygwin shell, but fails outside (in a DOS shell)

Steps To Reproducecompile the attached ml file :
ocamlbuild bugMkTime.native -tag use_unix -no-links
then
_build/bugMkTime.native

In a "Dos" or "MsysGit" shell, the output is
 more than one hour is 1.000000 second
 one hour is 0.000000 second
 Fatal error: exception Unix.Unix_error(32, "mktime", "")
 

while in a cygwin shell (with the same executable file), the output is correct :
 more than one hour is 3601.000000 second
 one hour is 3600.000000 second
 less than one hour is 3599.000000 second
TagsNo tags attached.
Attached Files? file icon bugMkTime.ml [^] (347 bytes) 2013-10-29 17:18 [Show Content]

- Relationships

-  Notes
(0010538)
protz (manager)
2013-10-29 18:11

Are you positive that you're running the exact same executable?
(0010566)
daweil (reporter)
2013-11-03 20:47

Yes.
The executable is build once with ocamlbuild in cygwin.
And executed first in cygwin and then outside in a Dos shell.

Can you reproduce the issue on one of your machine ?
(0010569)
protz (manager)
2013-11-04 10:51

Yes, I can confirm. This is strange indeed.
(0010570)
protz (manager)
2013-11-04 10:59
edited on: 2013-11-04 10:59

The Cygwin shell defines the TZ environment variable while the Windows shell does not. This is what's causing the difference in behavior. To reproduce the error in a Cygwin shell, just run

unset TZ


then launch your test program.

(0010571)
protz (manager)
2013-11-04 11:24

The underlying problem has something to do with DST (Dayling Saving Time). I strongly suspect this is not a bug, in the sense that:
1) the same problem happens on Linux

protzenk@sauternes:/tmp $ TZ=Europe/Paris ./a.out 
more than one hour is 1.000000 second
one hour is 0.000000 second
Fatal error: exception Unix.Unix_error(32, "mktime", "")
protzenk@sauternes:/tmp $ TZ=USA/New_York ./a.out 
more than one hour is 3601.000000 second
one hour is 3600.000000 second
less than one hour is 3599.000000 second


and 2)
  i) the documentation says in a fairly explicit manner that gmtime returns a tm struct whose tm_isdst field is always 0 (see http://msdn.microsoft.com/en-us/library/0z9czt0w.aspx [^])
  ii) both the windows and the unix implementation of OCaml's mktime set tm_isdst to -1, thus leaving it up to the environment to determine whether DST is active in the system's TZ or not (http://msdn.microsoft.com/en-us/library/d1y53h2a.aspx [^]).

The conclusion is, the date returned by gmtime(3599.), when interpreted with DST on or off, I have no idea which, represents one second before the epoch, thus a date that's not representable, hence the ERANGE message.

The documentation explicitly says that the tm argument of mktime is interpreted in the local time zone http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html [^]
(0010572)
protz (manager)
2013-11-04 11:24

I'm marking this as no change required, since I strongly suspect nothing's wrong with OCaml.
(0010573)
daweil (reporter)
2013-11-04 12:59

OK. As the behavior is surprising, could you just add something in the documentation of the gmtime function ?

- Issue History
Date Modified Username Field Change
2013-10-29 17:18 daweil New Issue
2013-10-29 17:18 daweil File Added: bugMkTime.ml
2013-10-29 18:11 protz Note Added: 0010538
2013-11-03 20:47 daweil Note Added: 0010566
2013-11-04 10:51 protz Note Added: 0010569
2013-11-04 10:59 protz Note Added: 0010570
2013-11-04 10:59 protz Note Edited: 0010570 View Revisions
2013-11-04 11:24 protz Note Added: 0010571
2013-11-04 11:24 protz Note Added: 0010572
2013-11-04 11:24 protz Status new => resolved
2013-11-04 11:24 protz Resolution open => no change required
2013-11-04 11:24 protz Assigned To => protz
2013-11-04 12:59 daweil Note Added: 0010573


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker