Add SystemTime::{MIN, MAX} #148825

cvengler · 2025-11-11T16:17:03Z

Accepted ACP: rust-lang/libs-team#692
Tracking Issue: #149067

This merge request introduces two new constants to SystemTime: MIN and MAX, whose values represent the maximum values for the respective data type, depending upon the platform.

Technically, this value is already obtainable during runtime with the following algorithm:
Use SystemTime::UNIX_EPOCH and call checked_add (or checked_sub) repeatedly with Duration::new(0, 1) on it, until it returns None.
Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever.

Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a checked_add and checked_sub on it fail.

In the future, the hope of the authors lies within the creation of a SystemTime::saturating_add and SystemTime::saturating_sub, similar to the functions already present in std::time::Duration.
However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction.
With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time.

This feature (and a related saturating version of checked_{add, sub} has been requested multiple times over the course of the past few years, most notably:

cvengler · 2025-11-11T16:26:53Z

For what it is worth: Right now, the Rust ecosystem does weird stuff in order to figure out a limit.

chrono for example picks arbitrary value that is far in the future but not too far in the future (as I have been told).

arti, the project I work upon and from which the motivation of this PR stems from, uses a custom SaturatingSystemTime, that is highly unportable and very Unix specific: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crates/tor-dirserver/src/mirror/operation.rs?ref_type=heads#L93

Kivooeo · 2025-11-11T19:13:00Z

I'm pretty sure, though I could be wrong that this will need an ACP first before any work

cvengler · 2025-11-11T19:57:44Z

I'm pretty sure, though I could be wrong that this will need an ACP first before any work

I am fine in opening such a thing.
We can always defer such an issue if not required. 🙂

cc @ijackson

rustbot · 2025-11-12T10:38:32Z

r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

cvengler · 2025-11-12T10:38:36Z

Marking this as ready for review, given that CI works now. 🎉

ChrisDenton · 2025-11-12T13:51:17Z

This will indeed require an ACP before this can be merged.

Kivooeo · 2025-11-12T15:30:02Z

I block this until ACP will accepted

cvengler · 2025-11-12T16:17:18Z

Alright, we already have a draft of an ACP in our pipeline.
Will push it in the next days or in the week of the 24th of November, as I will be on vacation the coming week.

ChrisDenton · 2025-12-13T08:39:59Z

However, I am more inclined towards changing the implementation to do cmp::max(dur.subsec_nanos() as u64 / 100, 1), but this might be something for a follow-up PR.

Ah, that does indeed sound good.

cvengler · 2025-12-13T09:18:58Z

However, I am more inclined towards changing the implementation to do cmp::max(dur.subsec_nanos() as u64 / 100, 1), but this might be something for a follow-up PR.

Ah, that does indeed sound good.

I pushed two commits.
One fixing the bug in checked_sub_duration and another one modifying the test case and documenting the status quo.

I hope this PR is the correct place for this?
Otherwise I could move this into a separate one, but I kind of want to get this PR into the main branch now.
My plan would be to open a follow-up MR changing this behavior, because it is probably a different kind of change to the ecosystem?

Alternatively, I would hard reset this to ac5c70a and open a new PR with those changes, setting this PR to "stale" before the other one is merged, then rebasing onto it.

There is a slight edge case when adding and subtracting a `Duration` from a `SystemTime`, namely when the duration itself is finer/smaller than the time precision on the operating systems. On most (if not all non-Windows) operating systems, the precision of `Duration` aligns with the `SystemTime`, both being one nanosecond. However, on Windows, this time precision is 100ns, meaning that adding or subtracting a `Duration` whose value is `< Duration::new(0, 100)` will result in that method behaving like an addition/subtracting of `Duration::ZERO`, due to the `Duration` getting rounded-down to the zero value.

The Windows implementation of `SystemTime::checked_sub` contains a bug, namely that it does not return `None` on values below 1601. This bug stems from the fact that internally, the time gets converted to an i64, with zero representing the anchor in 1601. Of course, performing checked subtraction on a signed integer generally works fine. However, the resulting value delivers undefined behavior on Windows systems. To mitigate this issue, we try to convert the resulting i64 to an u64 because a negative value should obviously fail there.

cvengler · 2025-12-13T12:46:41Z

This seems to be building again. 🎉

ChrisDenton · 2025-12-13T14:22:35Z

@bors r+

bors · 2025-12-13T14:22:38Z

📌 Commit d80348b has been approved by ChrisDenton

It is now in the queue for this repository.

…=ChrisDenton Add SystemTime::{MIN, MAX} Accepted ACP: <rust-lang/libs-team#692> Tracking Issue: <rust-lang#149067> --- This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform. Technically, this value is already obtainable during runtime with the following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None. Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever. Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail. In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`. However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction. With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time. This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably: * rust-lang#100141 * rust-lang#133525 * rust-lang#105762 * rust-lang#71224 * rust-lang#45448 * rust-lang#52555

…uwer Rollup of 5 pull requests Successful merges: - #148755 (Constify `DropGuard::dismiss` and trait impls) - #148825 (Add SystemTime::{MIN, MAX}) - #149894 (Update to mdbook 0.5) - #149930 (std: small `sys` refactor) - #149949 (Cleanup of attribute parsing errors) r? `@ghost` `@rustbot` modify labels: rollup

…=ChrisDenton Add SystemTime::{MIN, MAX} Accepted ACP: <rust-lang/libs-team#692> Tracking Issue: <rust-lang#149067> --- This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform. Technically, this value is already obtainable during runtime with the following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None. Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever. Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail. In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`. However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction. With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time. This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably: * rust-lang#100141 * rust-lang#133525 * rust-lang#105762 * rust-lang#71224 * rust-lang#45448 * rust-lang#52555

…uwer Rollup of 5 pull requests Successful merges: - #148755 (Constify `DropGuard::dismiss` and trait impls) - #148825 (Add SystemTime::{MIN, MAX}) - #149894 (Update to mdbook 0.5) - #149949 (Cleanup of attribute parsing errors) - #149955 (Fix typo in armv7a-vex-v5 documentation) r? `@ghost` `@rustbot` modify labels: rollup

…=ChrisDenton Add SystemTime::{MIN, MAX} Accepted ACP: <rust-lang/libs-team#692> Tracking Issue: <rust-lang#149067> --- This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform. Technically, this value is already obtainable during runtime with the following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None. Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever. Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail. In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`. However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction. With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time. This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably: * rust-lang#100141 * rust-lang#133525 * rust-lang#105762 * rust-lang#71224 * rust-lang#45448 * rust-lang#52555

Rollup of 8 pull requests Successful merges: - #148755 (Constify `DropGuard::dismiss` and trait impls) - #148825 (Add SystemTime::{MIN, MAX}) - #149272 (Fix vec iter zst alignment) - #149417 (tidy: Detect outdated workspaces in workspace list) - #149437 (Fix trailing newline in JUnit formatter) - #149773 (fix va_list test by adding a llvmir signext check) - #149894 (Update to mdbook 0.5) - #149955 (Fix typo in armv7a-vex-v5 documentation) r? `@ghost` `@rustbot` modify labels: rollup

…=ChrisDenton Add SystemTime::{MIN, MAX} Accepted ACP: <rust-lang/libs-team#692> Tracking Issue: <rust-lang#149067> --- This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform. Technically, this value is already obtainable during runtime with the following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None. Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever. Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail. In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`. However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction. With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time. This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably: * rust-lang#100141 * rust-lang#133525 * rust-lang#105762 * rust-lang#71224 * rust-lang#45448 * rust-lang#52555

Rollup of 8 pull requests Successful merges: - #148755 (Constify `DropGuard::dismiss` and trait impls) - #148825 (Add SystemTime::{MIN, MAX}) - #149272 (Fix vec iter zst alignment) - #149417 (tidy: Detect outdated workspaces in workspace list) - #149773 (fix va_list test by adding a llvmir signext check) - #149894 (Update to mdbook 0.5) - #149955 (Fix typo in armv7a-vex-v5 documentation) - #149972 (Enable to ping LoongArch group via triagebot) r? `@ghost` `@rustbot` modify labels: rollup

cvengler force-pushed the time_systemtime_limits branch from 143f4ce to 481fe49 Compare November 11, 2025 16:39

cvengler mentioned this pull request Nov 11, 2025

Feature Request: saturating_add(Duration) for SystemTime / Instant #71224

Open

This comment has been minimized.

Sign in to view

cvengler force-pushed the time_systemtime_limits branch from 481fe49 to 3ef3955 Compare November 11, 2025 22:18

cvengler marked this pull request as ready for review November 12, 2025 10:38

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 12, 2025

rustbot assigned ChrisDenton Nov 12, 2025

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Nov 12, 2025

This comment has been minimized.

Sign in to view

cvengler force-pushed the time_systemtime_limits branch from 3ef3955 to e5745aa Compare November 12, 2025 14:32

Kivooeo added S-blocked Status: Blocked on something else such as an RFC or other implementation work. needs-acp This change is blocked on the author creating an ACP. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 12, 2025

cvengler mentioned this pull request Nov 13, 2025

ACP: Add SystemTime::MIN and SystemTime::MAX rust-lang/libs-team#692

Closed

This comment has been minimized.

Sign in to view

cvengler force-pushed the time_systemtime_limits branch 2 times, most recently from 168b257 to b02ab4c Compare December 13, 2025 09:43

cvengler force-pushed the time_systemtime_limits branch from b02ab4c to 8decbdf Compare December 13, 2025 09:51

This comment has been minimized.

Sign in to view

cvengler force-pushed the time_systemtime_limits branch from 8decbdf to d80348b Compare December 13, 2025 11:35

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 13, 2025

JonathanBrouwer mentioned this pull request Dec 13, 2025

Rollup of 5 pull requests #149953

Closed

JonathanBrouwer mentioned this pull request Dec 13, 2025

Rollup of 5 pull requests #149956

Closed

ChrisDenton mentioned this pull request Dec 14, 2025

Rollup of 7 pull requests #149974

Closed

ChrisDenton mentioned this pull request Dec 14, 2025

Rollup of 8 pull requests #149975

Closed

ChrisDenton mentioned this pull request Dec 14, 2025

Rollup of 8 pull requests #149979

Open

Uh oh!

Add SystemTime::{MIN, MAX} #148825

Are you sure you want to change the base?

Add SystemTime::{MIN, MAX} #148825

Conversation

cvengler commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cvengler commented Nov 11, 2025

Uh oh!

This comment has been minimized.

Kivooeo commented Nov 11, 2025

Uh oh!

cvengler commented Nov 11, 2025

Uh oh!

rustbot commented Nov 12, 2025

Uh oh!

This comment has been minimized.

cvengler commented Nov 12, 2025

Uh oh!

ChrisDenton commented Nov 12, 2025

Uh oh!

Kivooeo commented Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cvengler commented Nov 12, 2025

Uh oh!

ChrisDenton commented Dec 13, 2025

Uh oh!

cvengler commented Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

cvengler commented Dec 13, 2025

Uh oh!

ChrisDenton commented Dec 13, 2025

Uh oh!

bors commented Dec 13, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

12 participants

cvengler commented Nov 11, 2025 •

edited

Loading

Kivooeo commented Nov 12, 2025 •

edited

Loading

cvengler commented Dec 13, 2025 •

edited

Loading