# \`Instant::PAST\_VALUE\` constant?

**URL:** <https://internals.rust-lang.org/t/instant-past-value-constant/24297>\
**Category:** libs\
**Created:** [May 12, 2026, 6:26pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297 "2026-05-12T18:26:01Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![JarredAllen](https://avatars.discourse-cdn.com/v4/letter/j/a183cd/32.png) [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Post date:** [May 12, 2026, 6:26pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/1 "2026-05-12T18:26:01Z")

</div>

I often find that it would be useful to have a value for `Instant` which is some arbitrary point in time which is guaranteed to be in the past. On Linux (which I know most about), this should be doable by just creating `Timespec::zero()`, but I don't know enough about the other platforms, is there something about those that prevents this constant from existing?

---

<div class="post-metadata">

**Author:** ![ais523](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@ais523](https://internals.rust-lang.org/u/ais523)\
**Post date:** [May 12, 2026, 7:02pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/2 "2026-05-12T19:02:52Z")

</div>

One potential problem I can foresee is that because this is loosely defined (there are many possible values that all work), it might cause compatibility problems going forwards (where we might have a reason to change it from one value to a different value, but that might break existing code that is, e.g., using it as a sentinel), or where it's used as a sentinel on one platform and then an attempt is made to read it from a different platform where the value is different (although `Instant` is already platform-specific enough that such code would already likely be broken, so maybe that isn't an issue).

I assume that the reason why you want this rather than just using `Instant::now()` is so that it can be a compile-time constant? (Guaranteeing that an `Instant` is _strictly_ in the past is difficult due to the possibility of a Rust program running during very early boot, before the timestamp has had a chance to change from its minimum value.)

---

<div class="post-metadata">

**Author:** ![JarredAllen](https://avatars.discourse-cdn.com/v4/letter/j/a183cd/32.png) [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Post date:** [May 12, 2026, 7:15pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/3 "2026-05-12T19:15:04Z")

</div>

Yes, that's why I want this over calling that function. It would also work for me if it was allowed to be the past or the present.

As for your concerns about people using it as a sentinel, I assume it would be fine so long as the docs come with a disclaimer that it's not to be used as a sentinel value, like [`NonNull::dangling()`](https://doc.rust-lang.org/core/ptr/struct.NonNull.html#method.dangling) does. I haven't heard of any errors from someone mis-using that value as a sentinel.

---

<div class="post-metadata">

**Author:** ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)\
**Post date:** [May 12, 2026, 7:21pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/4 "2026-05-12T19:21:51Z")

</div>

I think it would make sense to use a different definition: `Instant::MIN`. This would be always the earliest representable instant, so there is no arbitrary choice. It would be useful in more situations, such as the start of a range of instants, or guards against numeric overflow.

It would have to be documented as platform-specific, and not guaranteed to remain the same on each platform, of course.

---

<div class="post-metadata">

**Author:** ![toc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/toc/32/6692_2.png) [@toc](https://internals.rust-lang.org/u/toc)\
**Post date:** [May 13, 2026, 3:14am UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/5 "2026-05-13T03:14:11Z")

</div>

> [@JarredAllen](#):
>
> On Linux

Not answering the main question, but by the way `let old: Instant = unsafe { mem::zeroed() }` does exist as a workaround.

---

<div class="post-metadata">

**Author:** ![Noratrieb](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/noratrieb/32/12440_2.png) [@Noratrieb](https://internals.rust-lang.org/u/Noratrieb)\
**Post date:** [May 13, 2026, 5:18am UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/6 "2026-05-13T05:18:27Z")

</div>

It does not, do not ever do that. Instant makes no guarantees about its layout. What's the use case here?

---

<div class="post-metadata">

**Author:** ![JarredAllen](https://avatars.discourse-cdn.com/v4/letter/j/a183cd/32.png) [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Post date:** [May 13, 2026, 6:03pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/7 "2026-05-13T18:03:05Z")

</div>

The most common use-case I have is if I'm setting up a struct where, whenever a method gets called, it needs to do something if it hasn't recently enough. So I end up with something like this:

```rust
pub struct FooDoer {
    last_bar_timestamp: Instant,
    ..
}

impl FooDoer {
    pub fn do_foo(&mut self) {
        if self.last_bar_timestamp.elapsed() >= Duration::from_secs(1) { self.do_bar(); }
        ..
    }
    fn do_bar(&mut self) {
        self.last_bar_timestamp = Instant::now();
        ..
    }
}

```

But then, when I go to construct a `FooDoer`, then I have a few options for how to handle constructing the timestamp:

1. I can use `Instant::now()`, which has a syscall and so it's impossible to do it at const-time (and maybe subtract the interval if I need it to happen on the first time).
2. I can use `None` to accurately indicate that it hasn't happened yet, but then I have to rewrite everything to handle an option that will only be an option on the first time.
3. I can use something like the unsafe casting GP mentioned to construct an `Instant` which I know is valid and in the past, but then I'm going against the stdlib public API and that's liable to be broken on an update.

And also, it often doesn't matter much when exactly the first call to `do_bar()` happens, so I could get around all of that if I just had a constant which is guaranteed to not be in the future, hence why I suggested just that as the guarantee.

---

<div class="post-metadata">

**Author:** ![Vorpal](https://avatars.discourse-cdn.com/v4/letter/v/aca169/32.png) [@Vorpal](https://internals.rust-lang.org/u/Vorpal)\
**Post date:** [May 14, 2026, 3:32pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/8 "2026-05-14T15:32:01Z")

</div>

Couldn't you store the time of the program startup into a `OnceLock` or `LazyLock` and use that?

---

<div class="post-metadata">

**Author:** ![toc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/toc/32/6692_2.png) [@toc](https://internals.rust-lang.org/u/toc)\
**Post date:** [May 14, 2026, 4:11pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/9 "2026-05-14T16:11:28Z")

</div>

Storing the program startup time still isn't const, and makes this logic wrong for the first second after startup:

> [@JarredAllen](#):
>
> ```rust
> if self.last_bar_timestamp.elapsed() >= Duration::from_secs(1) { self.do_bar(); }
> 
> ```

Granted that logic is still iffy for `Instant::MIN` on devices which zero their timers to boot up (but that's probably fine).

---

<div class="post-metadata">

**Author:** ![m-ronchi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/m-ronchi/32/11489_2.png) [@m-ronchi](https://internals.rust-lang.org/u/m-ronchi)\
**Post date:** [May 14, 2026, 4:33pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/10 "2026-05-14T16:33:49Z")

</div>

you could have a `next_bar_timestamp` instead, initialized with `Instant::now() + Duration::from_secs(1)` and then you check if `next_bar_timestamp <= Instant::now()`

---

<div class="post-metadata">

**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\
**Post date:** [May 14, 2026, 5:37pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/11 "2026-05-14T17:37:52Z")

</div>

> [@toc](#):
>
> Granted that logic is still iffy for `Instant::MIN` on devices which zero their timers to boot up (but that's probably fine).

This is not a niche thing -- `CLOCK_MONOTONIC` is counted from boot time on Linux and probably many others. But for the 1 second delay in this example, I agree it's probably fine.

Another quirk of `MIN` is that this could be **far** in the past, e.g. on Unix targets that use `tv_sec: i64`, versus Windows with unsigned `Instant(Duration)`. So the range of `Instant::MIN.elapsed()` could be wildly different!

---

<div class="post-metadata">

**Author:** ![MichaelV](https://avatars.discourse-cdn.com/v4/letter/m/90db22/32.png) [@MichaelV](https://internals.rust-lang.org/u/MichaelV)\
**Post date:** [May 14, 2026, 10:52pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/12 "2026-05-14T22:52:35Z")

</div>

I often have issues in examples and test, with postgres not allowing to write chrono datetimeTZ min(), because it is too small. The fix is to use unix epoch zero instead.

So I agree, minimum values is too early. Related: Gregoran calendar issues

---

<div class="post-metadata">

**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\
**Post date:** [May 14, 2026, 10:58pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/13 "2026-05-14T22:58:57Z")

</div>

> [@MichaelV](#):
>
> Related: Gregoran calendar issues

Big Bang issues even -- `i64::MIN` seconds would be over 292 billion years ago!

---

<div class="post-metadata">

**Author:** ![riking](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/riking/32/2818_2.png) [@riking](https://internals.rust-lang.org/u/riking)\
**Post date:** [May 16, 2026, 3:38pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/14 "2026-05-16T15:38:57Z")

</div>

Swift calls these constants `DISTANT_PAST` and `DISTANT_FUTURE`.

---

<div class="post-metadata">

**Author:** ![jvcmarcenes](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jvcmarcenes/32/11971_2.png) [@jvcmarcenes](https://internals.rust-lang.org/u/jvcmarcenes)\
**Post date:** [May 16, 2026, 9:13pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/15 "2026-05-16T21:13:10Z")

</div>

Can't you start the timestamp with `Instant::now() - Duration::from_secs(1)`?

---

<div class="post-metadata">

**Author:** ![jdahlstrom](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jdahlstrom/32/3351_2.png) [@jdahlstrom](https://internals.rust-lang.org/u/jdahlstrom)\
**Post date:** [May 16, 2026, 10:18pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297/16 "2026-05-16T22:18:34Z")

</div>

No, because the use case was having the value available in `const`. Moreover, that subtraction may panic.