|Anonymous | Login | Signup for a new account||2015-01-25 13:19 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006285||OCaml||OCaml standard library||public||2014-01-02 01:57||2014-06-05 17:33|
|Target Version||Fixed in Version|
|Summary||0006285: Unix st_mtime has only second-level resolution|
|Description||stat.c (in the `unix` module) uses the old second-level precision data attributes of linux `stat` results:|
It should use the newer, subsecond-precision attributes where available. Jane Street Core does this:
|Steps To Reproduce||The following script always prints a whole number for `mtime`, despite other programs on the same machine/OS accessing sub-second resolution for `mtime` (e.g python):|
Ocaml.packs := ["unix"]
let () =
let this_file = Array.get Sys.argv 0 in
let stats = Unix.stat this_file in
printf "mtime: %f" stats.st_mtime
|Tags||No tags attached.|
I'm putting this as a feature wish, because it is.
Yes, it would be a nice touch to support subsecond resolution here. I am concerned about the three different ways to access the nanosecond parts: a solid configure-time test is needed here, because Jane Street's code seems to assume either Linux, MacOS X, or BSD, but nothing else.
I am also surprised at the "1000000000.0f" constant in their code. By forcing computation to single precision, rounding errors become much larger (up to 1.1 ns instead of 6e-8 ns for double precision). Not that it matters much, but as a floating-point nit-picker I *had* to point it out.
|2014-01-02 01:57||gfxmonk||New Issue|
|2014-05-30 15:25||shinwell||Status||new => confirmed|
|2014-06-05 17:33||xleroy||Note Added: 0011683|
|2014-06-05 17:33||xleroy||Severity||minor => feature|
|Copyright © 2000 - 2011 MantisBT Group|