Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move fs::Metadata::modified to modified_as_ms and reserve for the real Datetime type #846

Closed
m13253 opened this issue Feb 14, 2015 · 1 comment

Comments

@m13253
Copy link

m13253 commented Feb 14, 2015

As is documented here: std::fs::Metadata::modified, method modifed returns the modification time in milliseconds since the epoch.

We don't yet have a Datetime yet. We even haven't decided which epoch to use at the moment! But we will surely have one some time in the future.

I suggest we move modified to modified_as_ms and reserve for the real Datetime type.

My reasons:

  1. If we don't do that, inconsistency will be introduced when the real Datetime type is invented.
  2. Some filesystems (e.g. ext4) provide modification time in a nanosecond accuracy (10-9s). Milliseconds are far not enough, a single u64 is far not enough.
  3. Reserving in advance will reduce the pain at the transition. Instead of making old codes fail to compile, we can issue a "deprecated" warning then, to let the programmer switch to the final real modified.

Related PR #739

@m13253 m13253 changed the title Move fs::Metadata::modified to modified_as_ms and reserve for the real Datetime type Move fs::Metadata::modified to modified_as_ms and reserve for the real Datetime type Feb 14, 2015
@m13253 m13253 changed the title Move fs::Metadata::modified to modified_as_ms and reserve for the real Datetime type Move fs::Metadata::modified to modified_as_ms and reserve for the real Datetime type Feb 14, 2015
@alexcrichton
Copy link
Member

Thanks for the issue! This will definitely come up in stabilizing Metadata::modified, and as-is it is definitely not slated for stabilization (for the exact reasons you specify). As a result I'm going to close this issue as we probably don't want to open an RFC issue for all unstable APIs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants