Skip to content

Tracking issue for SystemTime::UNIX_EPOCH #49502

New issue

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

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

Already on GitHub? # to your account

Closed
sfackler opened this issue Mar 30, 2018 · 9 comments
Closed

Tracking issue for SystemTime::UNIX_EPOCH #49502

sfackler opened this issue Mar 30, 2018 · 9 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@sfackler
Copy link
Member

Added in #49501

@sfackler sfackler added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Mar 30, 2018
@sfackler
Copy link
Member Author

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Apr 23, 2018

Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Apr 23, 2018
@sfackler
Copy link
Member Author

For background, this is currently a stable constant in std::time, and this issue tracks it as an associated constant of SystemTime, which is way more discoverable.

@rfcbot
Copy link
Collaborator

rfcbot commented Apr 25, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Apr 25, 2018
@rfcbot rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label May 5, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented May 5, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

@rfcbot rfcbot removed the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label May 5, 2018
bors added a commit that referenced this issue May 29, 2018
@losvedir
Copy link

losvedir commented Jul 7, 2018

For others that found themselves on this issue from a compilation error on rust 1.27, I fixed it by changing:

use std::time::SystemTime;
SystemTime::now().duration_since(SystemTime::UNIX_EPOCH);

to

use std::time::{SystemTime, UNIX_EPOCH};
SystemTime::now().duration_since(UNIX_EPOCH);

@SimonSapin
Copy link
Contributor

@losvedir Was the error message about the feature being unstable? The module-level constant is older, but the associated constant on the type was stabilized in 1.28 which is currently in beta.

@losvedir
Copy link

losvedir commented Jul 7, 2018

Yes, the error I got was:

error[E0658]: use of unstable library feature 'assoc_unix_epoch' (see issue #49502)
   --> src/main.rs:127:38
    |
127 |     SystemTime::now().duration_since(SystemTime::UNIX_EPOCH).expect("unix time can't be calculated").as_secs() as u32
    |                                      ^^^^^^^^^^^^^^^^^^^^^^

I think I found the SystemTime::UNIX_EPOCH approach on stack overflow. I'm a brand new rustacean (?) and it wasn't immediately obvious to me from this issue (linked in the compilation error) or the docs that there was a soon-to-be-deprecated (I imagine) approach that works on stable currently.

@SimonSapin
Copy link
Contributor

I don’t know that we’re gonna deprecate the module-level constant. It’s sometimes slightly less convenient, but not "harmful" enough that we should actively push existing users to migrate.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants