Add explicit or zero constructor for std::time::Instant

57abf2c
Opened by Diggory Hardy at 2024-03-19 14:53:05

I'd like to be able to construct an Instant with value 0 (whatever epoch that is, I don't care).

Motivation: we have code to schedule timeouts taking a Duration. We have a mock version of the same scheduler which doesn't use real time but has the same API, and uses Instant internally (simply because converting between Instant and Duration is convenient and gives us mock code closer to the real code). Since the only way of constructing an Instant at the moment is Instant::now(), we currently store a "start time" when constructing the scheduler and compare all times to that; this would be simpler if we could simply use zero.

  1. Updated: see below

    I'd like to be able to construct an Instant with value 0 (whatever epoch that is, I don't care).

    Motivation: we have code to schedule timeouts taking a Duration. We have a mock version of the same scheduler which doesn't use real time but has the same API, and uses Instant internally (simply because converting between Instant and Duration is convenient and gives us mock code closer to the real code). Since the only way of constructing an Instant at the moment is Instant::now(), we currently store a "start time" when constructing the scheduler and compare all times to that; this would be simpler if we could simply use zero.

    Diggory Hardy at 2022-01-18 12:26:53

  2. I would personally be very hesitant to add a constructor which produces a value with no semantic meaning at all.

    Steven Fackler at 2017-03-30 05:20:17

  3. Unless the epoch ("zero time") is dependant on the platform, it does have semantic meaning.

    Diggory Hardy at 2017-03-30 08:16:51

  4. The epoch for Instant is completely arbitrary and has zero guarantees of being the same across platforms. Current implementations are at most consistent between processes on a given boot of a single machine, rebooting will change the epoch. Rust itself however doesn't guarantee that the epoch will even stay the same between processes, it merely guarantees that Instant is monotonic and that you can compare two Instants within a given process to find out how much time has elapsed.

    Peter Atashian at 2017-03-30 13:23:22

  5. Fair enough. Doesn't answer my motivation involving mocks, but easy enough to work around anyway.

    Diggory Hardy at 2017-03-31 07:59:09

  6. I'd like to revisit this if possible, but with a different name than "zero" (lets say "start" here, though "default" may be better).

    I would personally be very hesitant to add a constructor which produces a value with no semantic meaning at all.

    The semantics would be limited to:

    • Instant::start() is invariant (same value each time called within the process)
    • Instant::start() < Instant::now() at any point in the program

    Motivation:

    1. Default: as noted in #50800, T::default() is (generally) expected to yield an invariant value. This meets that requirement.
    2. Initialising a "time of last event" field where Instant::now() is acceptable: Instant::start() would almost always be better (it's constant, avoids a system call, and it is very likely that time.elapsed() > duration for any duration one would care about.
    3. Repeating animations where the start doesn't matter; for example a flashing animation might be based on Instant::start().elapsed().as_secs_f64() % period.

    Anti-motivation:

    1. As noted in (2) above, one might expect Instant::start().elapsed() > duration for any duration of interest, but this is not guaranteed and should not be relied upon — non-portable behaviour.
    2. Instant values are not portable between processes. This gives a workaround letting users attempt to do so: time - Instant::start() is a Duration.

    Diggory Hardy at 2022-01-18 12:25:57

  7. Relevant internals thread: Impl Default for std::time::Instant.

    Interesting point: the semantics of Default are poorly defined. I'm not sure whether that's a point in favour or against this proposal.

    Diggory Hardy at 2022-01-18 12:33:44

  8. Crates (like Stakker) uses Instant and promotes the use of virtual time. For virtual time, having the Instant be set to some random nondeterministic value is insane.

    Tommy Thorn at 2022-05-26 18:52:26

  9. Triage: Adding a somewhat controversial API to std would need to provide strong benefits to be justified. Is there some case where Option<Instant> or a custom enum would not be sufficient?

    Initialising a "time of last event" field where Instant::now() is acceptable

    I don't fully understand this example. Maybe you can give some concrete example code?

    Repeating animations where the start doesn't matter

    Any Instant will work as long as it is the same one, which is easy enough to implement without extending the API surface of Instant.

    Martin Nordholts at 2024-03-19 14:53:05