Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006215OCamlotherlibspublic2013-10-29 17:182015-12-11 19:24
Assigned Toprotz 
StatusclosedResolutionno 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

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 [^] (347 bytes) 2013-10-29 17:18 [Show Content]

- Relationships

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

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

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 ?
protz (manager)
2013-11-04 10:51

Yes, I can confirm. This is strange indeed.
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.

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 [^])
  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 ( [^]).

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 [^]
protz (manager)
2013-11-04 11:24

I'm marking this as no change required, since I strongly suspect nothing's wrong with OCaml.
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:
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
2015-12-11 19:24 xleroy Status resolved => closed
2017-02-23 16:42 doligez Category OCaml otherlibs => otherlibs

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker