Change:
/// } /// ``` /// <ins> /// # OS-specific behaviors /// /// An `Instant` is a wrapper around system-specific types and it may behave /// differently depending on the underlying operating system. For example, /// the following snippet is fine on Linux but panics on macOS: /// /// ```no_run /// use std::time::{Instant, Duration}; /// /// let now = Instant::now(); /// let max_nanoseconds = u64::MAX / 1_000_000_000; /// let duration = Duration::new(max_nanoseconds, 0); /// println!("{:?}", now + duration); /// ``` /// </ins> /// # Underlying System calls /// Currently, the following system calls are being used to get the current time using `now()`: ///

Discussion:
When investigating I noticed several inconsistencies in . I prepared two short snippets Both of the attached snippets are properly executed on linux (), but they panic on macos. snippet A panics with snippet B panics with This is an inconsistent behaviour of standard library and I believe that above snippets should panic (or work) on all platforms in the same way
is a wrapper around the most precise available time source on each OS. Those sources differ in the size of their supported ranges but you should generally be able to assume they'll work with within a range of 100 or so years.
Moreover, we've run into this issue on Windows too. The following test passes on Linux, but fails on Windows: I also think that the behavior must be consistent on all three main platforms, at least. This issue might be related:
is also a wrapper around the underlying system type. They do not all support times that are 300 billion years in the future.
I see your point, but what we're asking for, is to make behaviour consistent on every platform.
The behavior can't be consistent across platforms, because this is inherently platform specific behavior. Different platforms support different ranges and have different precisions.
At the very least, this ought to be better documented. There aren't any explicit warnings that is platform-dependent (apart from the name specifically, I don't think this is ever obvious). On the other hand, unless the documentation regarding is modified from "A type to represent a span of time, typically used for system timeouts." to "A type representing a span of system time." (or equivalent), I don't see why this restriction should be made — people are going to use it for non-system-related tasks at the moment, and as such the inconsistent behaviour is unexpected and poorly abstracted, even if they are in corner cases.
itself is platform independent. It's just and which are platform specific, and adding (or subtracting) a to an or can cause overflow on some platforms and not others. But yes, better documentation is a good idea.
This appears to be because on non-mac unix systems is stored as seconds and nanoseconds (independently) whereas on on macOS it's stored as a , representing nanos since the unix epoch. A workaround for this would be to use instead, which uses stores seconds and nanoseconds seperately on all platforms.
no, behaves different on different platforms as well.

encountered this error recently. When doing pure time calculations one would expect that adding a nanosecond would give a duration of 1 nanosecond. (x + Duration::fromnanos(1)).durationsince(x) does not return a nanosecond on windows. Is there any argument for not making the Instant nanosecond-precise regardless of platform and just truncate it when doing syscalls?
one for you
I'm not sure, if my problem is worth it's own issue: When using std::time::Duration, the function returns an u128. However it is impossible to import it, without casting to u64, since has no u128 overload.
I encountered something strange on Windows 10. In an unittest with the following code I get some error, in an unreproducible way : sometimes it works for days, and sometimes it keeps failing until I change the duration down to 1800 seconds. Putting it back to 3600 makes the test fails again, the only way to avoid the overflow is to change the code to : After that I can move my code back to and it starts working again. I am really wondering what is going on compiler and/or OS side to have such behavior.
provides time since something (at least on Windows it seems to be time since boot), you can verify it by using macro. Then you are subtracting 1 hour from that. On Windows cannot be in the past (in other words have negative value) but on Linux it's allowed. This is platform specific limitation and there is not much that can be done about it.
This is it, thanks a bunch. For my use case better suite then.
I can add the documentation about the system-specificities but I'm not exactly clear on where it should go: or the relevant types ? I'm in favour of the former, is not system-dependent and can still be used to force a panic but I would like confirmation.