Consider making std::time::SystemTime platform-independent (original) (raw)

It was found in #44220 (comment) that certain systems in Tier-2 support still uses a 32-bit time_t. SystemTime on them will suffer from the Year-2038 problem, and also cannot perform arithmetic for a duration >68 years. This introduces a portability hazard, in which on some systems the time arithmetic works normally, and in some more legacy system it suddenly panics.

The SystemTime struct is a wrapper around timespec on Unix and Redox, and FILETIME on Windows. Nevertheless, the public API involving SystemTime never exposes this detail:

• You cannot construct a SystemTime from a timespec/FILETIME, nor the other way round
• The only place where SystemTime interacts with the OS are being returned
  1. SystemTime::now, returning a SystemTime
  2. Metadata::{modified, accessed, created}, returning an io::Result<SystemTime>
• There are no OS-specific APIs reading a SystemTime.

This means expanding the precision and range of SystemTime is safe. In fact, we could even make the SystemTime structure itself platform-agnostic, just like Duration:

struct SystemTime { secs: i64, nanos: u32, }