bors 24a0eecf03 Auto merge of #96657 - cuviper:time64, r=joshtriplett ... 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		2022-05-07 17:53:59 +00:00
..
benches	mv std libs to library/	2020-07-27 19:51:13 -05:00
primitive_docs	Add primitive documentation to libcore	2021-09-12 02:23:08 +00:00
src	Auto merge of #96657 - cuviper:time64, r=joshtriplett	2022-05-07 17:53:59 +00:00
tests	Fold aarch64 feature +fp into +neon	2022-03-22 15:14:33 -07:00
build.rs	std: Get the standard library compiling for wasm64	2021-11-10 08:35:42 -08:00
Cargo.toml	Update libc dependency of std to 0.2.125.	2022-04-29 16:45:17 +02:00