Conversation
…ime`s to clarify handling of failure
rustbot
added
S-waiting-on-review
Collaborator
hkBst
suggested changes
Jan 27, 2026
| /// | ||
| /// If successful, <code>[Ok]\([Duration])</code> is returned where the duration represents | ||
| /// the amount of time elapsed from the specified measurement to this one. | ||
| /// If `self` lies further ahead, or at the same point in time compared to `earlier`, |
Member
There was a problem hiding this comment.
This seems a very roundabout way to express that earlier is not later than self.
| /// Also note that the `UNIX_EPOCH` may not be equal to the minimum representable | ||
| /// value of [`SystemTime`]; [`SystemTime::MIN`] is platform-dependent. | ||
| /// Thus, the developer ought to anticipate that comparison with `UNIX_EPOCH` may | ||
| /// result in "failure", even within legitimate, real-world use-cases. |
Member
There was a problem hiding this comment.
One of the complaints was that pretending that the Err variant represents a failure contributes to wrong interpretation of the return value of this function.
| /// Returns an [`Err`] if `earlier` is later than `self`, and the error | ||
| /// contains how far from `self` the time is. | ||
| /// Returns an [`Err`] if `earlier` is later than `self`, where the error contains how far | ||
| /// from `self` the time is, publicly exposed through [`SystemTimeError::duration`]. |
Member
There was a problem hiding this comment.
I'm not sure what "publicly exposed through" is supposed to mean.
| /// returned where the duration represents the amount of time elapsed from | ||
| /// This function may return a [`SystemTimeError`] as the underlying system clock | ||
| /// is susceptible to drift and updates (e.g., the system clock could go backwards), | ||
| /// so this function might not always succeed. If successful, an [`Ok::<Duration>`](Ok) |
Member
There was a problem hiding this comment.
Another instance of the failure/success analogy which should be avoided.
Member
|
@rustbot author |
rustbot
added
S-waiting-on-author
Collaborator
|
Reminder, once the PR becomes ready for a review, use |
|
Ping from triage: @david-d-h - can you post your status on this PR? I'll be closing because of inactivity otherwise. Thanks |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This documentation change is meant to clarify that
SystemTimes may (platform-dependently) be "less" than theUNIX_EPOCHand a developer ought to take care in comparing between the two, as this might lead to an error. It also explicitly mentionsSystemTimeError::durationfor when such an error does occur.I'm not sure on whether it would be helpful to document such a thing on the
SystemTimeitself rather than on it's methods and assoc consts? Perhaps it could be, since the documentation for the item also mentions theUNIX_EPOCHanchor and encourages comparisons with it. Anyways, open to suggestions.closes #52522