24a0eecf03
Use 64-bit time on 32-bit linux-gnu The standard library suffered the [Year 2038 problem][Y2038] in two main places on targets with 32-bit `time_t`: - In `std::time::SystemTime`, we stored a `timespec` that has `time_t` seconds. This is now changed to directly store 64-bit seconds and nanoseconds, and on 32-bit linux-gnu we try to use `__clock_gettime64` (glibc 2.34+) to get the larger timestamp. - In `std::fs::Metadata`, we store a `stat64`, which has 64-bit `off_t` but still 32-bit `time_t`, and unfortunately that is baked in the API by the (deprecated) `MetadataExt::as_raw_stat()`. However, we can use `statx` for 64-bit `statx_timestamp` to store in addition to the `stat64`, as we already do to support creation time, and the rest of the `MetadataExt` methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support, but that's not something Rust can change. There remain a few places that need `timespec` for system call timeouts -- I leave that to future work. [Y2038]: https://en.wikipedia.org/wiki/Year_2038_problem |
||
|---|---|---|
| .. | ||
| alloc | ||
| backtrace@b02ed04a7e | ||
| core | ||
| panic_abort | ||
| panic_unwind | ||
| portable-simd | ||
| proc_macro | ||
| profiler_builtins | ||
| rtstartup | ||
| rustc-std-workspace-alloc | ||
| rustc-std-workspace-core | ||
| rustc-std-workspace-std | ||
| std | ||
| stdarch@d215afe9d1 | ||
| test | ||
| unwind | ||