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.

cvengler · 2025-11-24T15:53:45Z

Let me know if and when you want to get this squashed

bors · 2025-12-03T01:49:36Z

☔ The latest upstream changes (presumably #149560) made this pull request unmergeable. Please resolve the merge conflicts.

cvengler · 2025-12-03T11:29:22Z

Fixed conflicts by rebasing onto 672388e.

@ChrisDenton May I ask how the next steps here will look like? 🙂

bors · 2025-12-09T09:34:07Z

☔ The latest upstream changes (presumably #147572) made this pull request unmergeable. Please resolve the merge conflicts.

cvengler · 2025-12-09T17:14:43Z

Rebased to current git main.

rustbot · 2025-12-09T17:14:44Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

ChrisDenton · 2025-12-11T16:27:02Z

Given that this is nightly only and libs-api have accepted this in general, I'm ok with merging the current implementation and letting the discussion continue on the tracking issue. If there are more issues that need to be brought to the attention of libs-api then the tracking issue can be nominated for a team discussion.

Could you squish your commits?

cvengler · 2025-12-11T16:44:29Z

Given that this is nightly only and libs-api have accepted this in general, I'm ok with merging the current implementation and letting the discussion continue on the tracking issue. If there are more issues that need to be brought to the attention of libs-api then the tracking issue can be nominated for a team discussion.

Could you squish your commits?

done!

ChrisDenton · 2025-12-11T17:44:29Z

Thanks!

@bors r+

bors · 2025-12-11T17:44:32Z

📌 Commit 3f98375 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 10 pull requests Successful merges: - #142380 (Put negative implementors first and apply same ordering logic to foreign implementors) - #146584 (remove duplicated columns from `rustc_error_code::error_codes!`) - #148717 (Point at span within local macros even when error happens in nested external macro) - #148825 (Add SystemTime::{MIN, MAX}) - #149565 (rustdoc: Add unstable `--merge-doctests=yes/no/auto` flag) - #149770 (Rename some issue-* tests) - #149807 (Use ubuntu:24.04 for the `x86_64-gnu-miri` job) - #149850 (Remove "tidy" tool for `tests/rustdoc` testsuite) - #149863 (Do not suggest moving expression out of for loop when hitting `break` from desugaring) - #149867 (only resolve main in bin crates) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2025-12-11T21:09:25Z

@bors r-
https://github.com/rust-lang/rust/actions/runs/20146572689/job/57828597532#step:29:9732

#149890 (comment)

This commit introduces two new constants to SystemTime: `MIN` and `MAX`, whose value 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. Concrete implementation depending upon the platform is done in later commits. 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. Below are platform specifc notes: # Hermit The HermitOS implementation is more or less identitcal to the Unix one. # sgx The implementation uses a `Duration` to store the Unix time, thereby implying `Duration::ZERO` and `Duration::MAX` as the limits. # solid The implementation uses a `time_t` to store the system time within a single value (i.e. no dual secs/nanosecs handling), thereby implying its `::MIN` and `::MAX` values as the respective boundaries. # UEFI UEFI has a weird way to store times, i.e. a very complicated struct. The standard proclaims "1900-01-01T00:00:00+0000" to be the lowest possible value and `MAX_UEFI_TIME` is already present for the upper limit. # Windows Windows is weird. The Win32 documentation makes no statement on a maximum value here. Next to this, there are two conflicting types: `SYSTEMTIME` and `FILETIME`. Rust's Standard Library uses `FILETIME`, whose limit will (probably) be `i64::MAX` packed into two integers. However, `SYSTEMTIME` has a lower-limit. # xous It is similar to sgx in the sense of using a `Duration`. # unsupported Unsupported platforms store a `SystemTime` in a `Duration`, just like sgx, thereby implying `Duration::ZERO` and `Duration::MAX` as the respective limits.

cvengler · 2025-12-11T21:19:15Z

@bors r- https://github.com/rust-lang/rust/actions/runs/20146572689/job/57828597532#step:29:9732

#149890 (comment)

Should be fixed.

JonathanBrouwer · 2025-12-11T21:23:53Z

@bors try jobs=dist-various-2

Add SystemTime::{MIN, MAX} try-job: dist-various-2

rust-log-analyzer · 2025-12-11T22:12:04Z

The job dist-various-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)


error[E0308]: mismatched types
  --> library/std/src/sys/pal/uefi/time.rs:75:33
   |
75 |       pub const MIN: SystemTime = SystemTime::from_uefi(r_efi::efi::Time {
   |  _________________________________^
76 | |         year: 1900,
77 | |         month: 1,
78 | |         day: 1,
...  |
86 | |         pad2: 0,
87 | |     });
   | |______^ expected `SystemTime`, found `Option<SystemTime>`
   |
   = note: expected struct `pal::uefi::time::SystemTime`
                found enum `core::option::Option<pal::uefi::time::SystemTime>`
help: consider using `Option::expect` to unwrap the `core::option::Option<pal::uefi::time::SystemTime>` value, panicking if the value is an `Option::None`
   |
87 |     }).expect("REASON");
   |       +++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
[RUSTC-TIMING] std test:false 2.905
warning: `std` (lib) generated 1 warning

rust-bors · 2025-12-11T22:12:11Z

💔 Test for 022ace1 failed: CI. Failed jobs:

try - dist-various-2 (web logs, enhanced plaintext logs)

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

cvengler force-pushed the time_systemtime_limits branch from 2a3ae98 to 71b0663 Compare December 3, 2025 11:28

This comment has been minimized.

Sign in to view

cvengler force-pushed the time_systemtime_limits branch from 2a2c120 to 7e88aa2 Compare December 9, 2025 17:14

cvengler force-pushed the time_systemtime_limits branch from 7e88aa2 to 3f98375 Compare December 11, 2025 16:44

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 11, 2025

JonathanBrouwer mentioned this pull request Dec 11, 2025

Rollup of 10 pull requests #149890

Closed

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

cvengler force-pushed the time_systemtime_limits branch from 3f98375 to 71c14ef Compare December 11, 2025 21:18

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Dec 11, 2025

Auto merge of #148825 - cvengler:time_systemtime_limits, r=<try>

022ace1

Add SystemTime::{MIN, MAX} try-job: dist-various-2

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!

cvengler commented Nov 24, 2025

Uh oh!

bors commented Dec 3, 2025

Uh oh!

This comment has been minimized.

cvengler commented Dec 3, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

cvengler commented Dec 9, 2025

Uh oh!

rustbot commented Dec 9, 2025

Uh oh!

ChrisDenton commented Dec 11, 2025

Uh oh!

cvengler commented Dec 11, 2025

Uh oh!

ChrisDenton commented Dec 11, 2025

Uh oh!

bors commented Dec 11, 2025

Uh oh!

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

Uh oh!

Uh oh!

cvengler commented Dec 11, 2025

Uh oh!

JonathanBrouwer commented Dec 11, 2025

Uh oh!

This comment has been minimized.

rust-log-analyzer commented Dec 11, 2025

Uh oh!

rust-bors bot commented Dec 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

cvengler commented Nov 11, 2025 •

edited

Loading

Kivooeo commented Nov 12, 2025 •

edited

Loading

matthiaskrgr commented Dec 11, 2025 •

edited

Loading