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

Behaviour of Unix.{gmtime,localtime} on negative timestamps. #6921

Closed
vicuna opened this issue Jun 28, 2015 · 2 comments
Closed

Behaviour of Unix.{gmtime,localtime} on negative timestamps. #6921

vicuna opened this issue Jun 28, 2015 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Jun 28, 2015

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

  1. The wide interval ]-1;1[ of timestamps gets mapped to the epoch
  2. 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.

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

@vicuna
Copy link
Author

vicuna commented Jun 28, 2015

Comment author: @dbuenzli

Ach, the ASCII art gets garbled, see that with a fixed-font width.

@vicuna
Copy link
Author

vicuna commented Jul 25, 2015

Comment author: @xavierleroy

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.

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

1 participant