the minimum possible value of SystemTime has been reduced on nightly on Windows

[martintmk]

I am trying to convert the jiff's Timestamp::MIN value to SystemTime. While this works well on version 1.92, it fails on nightly-2025-10-18 build.

I tried this code:

use std::time::{Duration, SystemTime};

fn main() {
    // Alligned with jiff's Timestamp::MIN that is around 12000 years ago
    // https://github.com/BurntSushi/jiff/blob/42d83ff42a42b1cb5ff0be6f56818d4e6c13c5f5/src/timestamp.rs#L337
    let duration = Duration::from_secs(377_705_023_201);
    let epoch = SystemTime::UNIX_EPOCH;

    epoch.checked_sub(duration).unwrap();
}

I expected the above example to pass but instead, it panics with the following message:

thread 'main' (26540) panicked at src\main.rs:9:33:
called `Option::unwrap()` on a `None` value

Meta

rustc 1.94.0-nightly (56f24e00c 2025-12-29)
binary: rustc
commit-hash: 56f24e00c62ec2db9a8b407e7aef532caaf71062
commit-date: 2025-12-29
host: x86_64-pc-windows-msvc
release: 1.94.0-nightly
LLVM version: 21.1.8

Backtrace

thread 'main' (25348) panicked at src\main.rs:9:33:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: std::panicking::panic_handler
             at /rustc/dac38bd5539ee944505344739de3d33f03259109/library\std\src\panicking.rs:689
   1: core::panicking::panic_fmt
             at /rustc/dac38bd5539ee944505344739de3d33f03259109/library\core\src\panicking.rs:80
   2: core::panicking::panic
             at /rustc/dac38bd5539ee944505344739de3d33f03259109/library\core\src\panicking.rs:150
   3: core::option::unwrap_failed
             at /rustc/dac38bd5539ee944505344739de3d33f03259109/library\core\src\option.rs:2199
   4: enum2$<core::option::Option<std::time::SystemTime> >::unwrap
             at D:\.msrustup\packages\nightly.rust.tools.nightly-llvm-x86_64-pc-windows-msvc.1.94.0-ms-20251229.10014\tools\lib\rustlib\src\rust\library\core\src\option.rs:1016
   5: system_time_bug::main
             at .\src\main.rs:9
   6: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at D:\.msrustup\packages\nightly.rust.tools.nightly-llvm-x86_64-pc-windows-msvc.1.94.0-ms-20251229.10014\tools\lib\rustlib\src\rust\library\core\src\ops\function.rs:250

[ChrisDenton]

This was an intentional bugfix. Windows times start from 1601 (see FILETIME). Negative times are not supported.

[martintmk]

@ChrisDenton Could you provide more information about this change, or reference an issue that justifies this? What problems did the wider range of SystemTime values caused? Also, this would warrant some section in the docs for SystemTime as currently it does not mention anything about range of possible values being platform specific. This change could impact other time-related crates (time, chronos) and their interoperability with system time.

cc @BurntSushi The range of possible SystemTime values was changed on nightly. This might impact some of the jiff APIs, for example the conversion to SystemTime is no loner infallible:

https://github.com/BurntSushi/jiff/blob/42d83ff42a42b1cb5ff0be6f56818d4e6c13c5f5/src/timestamp.rs#L2822

[ChrisDenton]

While it's not as explicitly documented as perhaps it should be, the SystemTime docs do state in various places that it's system dependent:

A measurement of the system clock... The size of a SystemTime struct may vary depending on the target operating system... The precision of SystemTime can depend on the underlying OS-specific time format

checked_sub:

Returns Some(t) where t is the time self - duration if t can be represented as SystemTime (which means it’s inside the bounds of the underlying data structure), None otherwise.

The underlying structure is a FILETIME which:

Contains a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC).

While that only implies unsigned, it is later made explicit:

It is not recommended that you add and subtract values from the FILETIME structure to obtain relative times. Instead, you should copy the low- and high-order parts of the file time to a ULARGE_INTEGER structure...

A ULARGE_INTEGER is defined as "a 64-bit unsigned integer value".

This is also important because various system file time functions apply special meaning to negative numbers.

For example, the SetFileTime function uses 0xFFFFFFFF to specify that a file's previous access time should be preserved.

Timer functions can also use the sign bit to switch between absolute and relative times. This does also imply that times greater than i64::MAX should also be considered out of range but that doesn't affect the minimum time.

[BurntSushi]

@martintmk Thanks for the heads up. Even aside from this issue, I think Jiff assuming something about the SystemTime representation is wrong. So I'll switch it to a TryFrom impl in Jiff 1.0 (see BurntSushi/jiff#467).

[workingjubilee]

...Well, I would have thought that the size and precision being varying, without specified constraints, would make clear that the range is also variable. But I suppose it is reasonable to imagine a world where all platforms agreed to encode the same data range in different ways. That would be a very reasonable, even nice world to live in. Maybe we'd even have no pointless DST changes!

...Unfortunately, we live in this one.