You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 6921 Reporter:@dbuenzli Status: closed (set by @xavierleroy on 2017-09-24T15:32:19Z) Resolution: not a bug Priority: normal Severity: minor Version: 4.02.2 Category: otherlibs Monitored by:@diml@hcarty@dbuenzli
Bug description
The implementation of Unix.gmtime casts a double value to time_t.
The wide interval ]-1;1[ of timestamps gets mapped to the epoch
Negative timestamps with fractional second get mapped to the second
that comme afterwards. E.g. all timestamps with a non-zero
subsecond precision in the instant 1969-31-12 23:59:59 UTC get
mapped to the epoch which I do not find especially intuitive.
would result in an better behaved timeline. However I'm unsure whether
this should be changed or not. If not, I think that the truncation
behaviour should be documented.
Note that POSIX time is formally undefined before the epoch (see [1])
and hence so is gmtime on negative timestamps however at least macosx
and linux do handle these negative integral timestamps correctly.
I appreciate your concern for precision, but we are really talking about the combination of two nonstandard things here, namely:
1- negative time stamps (before the epoch), and
2- fractional time stamps. Normally, the argument to gmtime is an integer, as returned by e.g. Unix.time. OCaml uses floats to represent timestamps because it's often convenient, and because it circumvents the limited range of type "int". So, yes, you can give a fractional timestamp to gmtime, but it's not really intended.
Quite frankly, I don't think we need to take any action here.
Original bug ID: 6921
Reporter: @dbuenzli
Status: closed (set by @xavierleroy on 2017-09-24T15:32:19Z)
Resolution: not a bug
Priority: normal
Severity: minor
Version: 4.02.2
Category: otherlibs
Monitored by: @diml @hcarty @dbuenzli
Bug description
The implementation of Unix.gmtime casts a double value to time_t.
https://github.com/ocaml/ocaml/blob/4.02/otherlibs/unix/gmtime.c#L42
The resulting truncation rounds towards zero and has the effect to have
a timeline that looks as follows:
-2 -1 0 1 2
... +----+----+----+----+ ...
]--->]--->|<---[<---[
This means that
that comme afterwards. E.g. all timestamps with a non-zero
subsecond precision in the instant 1969-31-12 23:59:59 UTC get
mapped to the epoch which I do not find especially intuitive.
I would argue that flooring the timestamp:
-2 -1 0 1 2
... +----+----+----+----+ ...
[<---[<---[<---[<---[
would result in an better behaved timeline. However I'm unsure whether
this should be changed or not. If not, I think that the truncation
behaviour should be documented.
Note that POSIX time is formally undefined before the epoch (see [1])
and hence so is gmtime on negative timestamps however at least macosx
and linux do handle these negative integral timestamps correctly.
Best,
Daniel
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
The text was updated successfully, but these errors were encountered: