std: Expose SystemTime accessors on fs::Metadata

[alexcrichton]

These accessors are used to get at the last modification, last access, and
creation time of the underlying file. Currently not all platforms provide the
creation time, so that currently returns Option.

[alexcrichton]

cc @rust-lang/libs, we'll likely want to discuss this a bit before landing, especially the choice about returning Option<SystemTime> from created (and of course some minor bikeshedding)

r? @aturon

[Gankra]

Could you elaborate on the "not all platforms support this" aspect? It seems from the PR that this is known to succeed or fail at compile time, which seems to imply that it fits in with our platform-specific extension traits. Are we expecting some platforms to have "truly conditional" support, or is the extension trait too annoying?

[pitdicker]

A creation time (birth time) is in the works for a few filesystems on Linux (like btrfs, ext4 and jfs), but most filesystems and older kernels will not support it. So an option looks right.

[alexcrichton]

@gankro currently it's a statically made decision based on the OS, but @pitdicker brings up an interesting point I had not thought of!

[retep998]

It may also be good to point out that even though all platforms do provide this value, not all platforms will actually keep it updated. I know at least on Windows there is an option to disable updating of the last access time.

[durka]

Linux too, with noatime.

[brson]

File access time is such a misfeature I wonder if this might not be very futureproof. Maybe places we might want to run std won't support that feature. I don't have concrete examples though, and there are probably lots of places were we've wed std to the union of unix + windows.

[retep998]

Maybe make all of the file times be Option just in case there is that weird platform or filesystem that doesn't have them.

[aturon]

Maybe make all of the file times be Option just in case there is that weird platform or filesystem that doesn't have them.

Not a bad idea (especially for the case of filesystem variance). Though I wonder if Result might be better, so that we can potentially provide detailed error information in the future.

[alexcrichton]

Updated with some tweaked docs and all methods returning io::Result instead of some fallible and some infallible

[aturon]

r=me implementation-wise. Given that these are all unstable, I'm OK going ahead and landing, but if you'd rather wait till the next libs meeting, that's fine too.

[alexcrichton]

Cool, I'm fine waiting for the libs meeting, wanna be sure we're on the same page.

[alexcrichton]

@bors: r=aturon cf74cd917feee816b2b7c5babe6aa6c99c87e40c

(carrying over from the libs triage meeting)

[alexcrichton]

Oh, and discussed during libs triage today, we concluded that it's fine to add these functions as unstable for now. We may want to revisit signatures and/or naming, but the functionality seems good.

[bors]

⌛ Testing commit cf74cd9 with merge 7ded903...

[bors]

💔 Test failed - auto-mac-64-nopt-t

[alexcrichton]

@bors: r=aturon

[bors]

📌 Commit 208cd38 has been approved by aturon

[bors]

⌛ Testing commit 208cd38 with merge 13cb16a...

[bors]

💔 Test failed - auto-mac-64-opt

[alexcrichton]

@bors: r=aturon 32cf074

[bors]

☔ The latest upstream changes (presumably #31360) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

@bors: r=aturon d1681bb

[bors]

⌛ Testing commit d1681bb with merge 7bcced7...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt