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

Is this crate deprecated? Or isn't it? What to use instead? #136

Closed
est31 opened this issue Jul 18, 2016 · 35 comments · Fixed by #138
Closed

Is this crate deprecated? Or isn't it? What to use instead? #136

est31 opened this issue Jul 18, 2016 · 35 comments · Fixed by #138

Comments

@est31
Copy link

est31 commented Jul 18, 2016

Maintainer's note: Yes, this crate is maintained. As of November 2019, a 0.2 release is in the works.

Original issue follows.


The repo lives under the rust-lang-deprecated organisation. https://github.com/rust-lang/time redirects to this repo. Does that mean this crate is deprecated?

If this crate is indeed deprecated, what should I use as replacement?

@alexcrichton
Copy link

Thanks for the report! This crate is currently "deprecated" in the sense that the rust-lang libs team isn't attempting to actively maintain it or pursue redesigns, but currently there aren't many replacements for its functionality quite just yet. It's essentially looking for other maintainers, if anyone steps up, or waiting for something to replace it.

The libs team, however, will continue to fix bugs in it though.

@est31
Copy link
Author

est31 commented Jul 18, 2016

I see. Officially unmaintained or not, this crate seems to be better maintained than many other smaller open source projects are.

Maybe it would be a good idea to put that info into the README to that others who have this question will see it? Then this issue can be closed :)

@alexcrichton
Copy link

Sounds good to me! I'll leave this open until the README is updated

@jhpratt
Copy link
Member

jhpratt commented Sep 10, 2019

@alexcrichton Any opposition to someone else taking over this crate? I'd be willing to bring things up to date: converting to 2018, removing anything that's deprecated, and (possibly) switching the backend to std::time.

@alexcrichton
Copy link

@sfackler @dtolnay @Kimundi @Amanieu @KodrAus do y'all have thoughts on transferring the time crate to a new owner? I don't personally have many thoughts myself.

@sfackler
Copy link

👍 !!

@jhpratt
Copy link
Member

jhpratt commented Sep 17, 2019

Just for reference, my view for the time crate is, apart from modernizing it, to make some pretty large changes eventually.

In a future version, I'd prefer to have newtypes over std::time::Duration, std::time::SystemTime, etc. that provide for new (and renamed) methods, parsing and display, and additional associated constants. This would allow for zero overhead with regard to std, and because it would implement Deref, it would allow for trivial conversion if someone needed parsing.

std has a very similar implementation to what this crate has, so why not defer to that instead, and in doing so also support more environments. Obviously that would would be a little ways off, but that's my general idea for the way forward.

@KodrAus
Copy link

KodrAus commented Sep 23, 2019

That sounds good to me! Should we set up a GitHub org to shift the crate into?

@alexcrichton
Copy link

Sounds like others either don't have thoughts or agree as well! @jhpratt would you prefer that we transfer the crate to you or a github org as @KodrAus mentions?

@jhpratt
Copy link
Member

jhpratt commented Sep 23, 2019

@alexcrichton No preference here. Either way others could remain in an "oversight" position to make sure I don't do anything stupid with it. Obviously the publishing rights to crates.io will be necessary as well.

Thank you!

@alexcrichton
Copy link

Ok, in that case I think I'd lean towards just transferring the crate to you @jhpratt and letting you organize it as you see fit. @KodrAus does that sound alright to you as well?

@Manishearth
Copy link

If y'all are making drastic changes I think that you should first fork it and create a different crate in its own org, potentially merging back in eventually as it matures. We should be careful about the time crate name on crates.io, IMO.

@KodrAus
Copy link

KodrAus commented Sep 27, 2019

My personal preference is towards organizations, just because it lets us manage commit and publish permissions in the one model.

@Manishearth Hmm, what if we spun time into an org, published any new releases under a time-preview name (which I just reserved in case), like futures-preview, and then pushed to time after a review?

@jhpratt @alexcrichton How does that sound to you?

@Manishearth
Copy link

That's roughly what I was thinking yeah

@jhpratt
Copy link
Member

jhpratt commented Sep 27, 2019

I personally don't care for -preview-type crates, because then a number of people tend to rely on that instead of the supposedly preferred one.

As I've said before, an organization is fine — I have no preference either way. I know that @alexcrichton mentioned transferring it to me personally, but I would certainly add other contributors with push access if desired.

@alexcrichton
Copy link

Ok so how about we do the following:

  • Spin up a time-rs organization (or some bikesheddable name)
  • Transfer this crate there
  • Give @jhpratt admin rights on the org and the crate, as well as me and @KodrAus
  • @jhpratt you can develop the crate and work towards the next release (0.2 or 1.0, depending on how you feel)
  • We can have an open community review of the next release before publication, and assuming that all goes well we give you, @jhpratt, publish rights to time on crates.io?

How's that sound?

@jhpratt
Copy link
Member

jhpratt commented Sep 30, 2019

@alexcrichton Sounds good to me.

@alexcrichton
Copy link

Ok! @jhpratt want to make an org, add me as an admin, and I'll transfer this repository in to the organization?

@jhpratt
Copy link
Member

jhpratt commented Sep 30, 2019

Done. Organization is rust-lang-community.

@alexcrichton
Copy link

Oh hm sorry rust-lang-community sounds like it sort of clashes with either being an official organization or related to the community team, perhaps an org focused just on the time crate for now?

@jhpratt
Copy link
Member

jhpratt commented Sep 30, 2019

Moved to time-rs, which should be clearer that it's not official.

@alexcrichton
Copy link

Ok! I've transferred the crate now. @jhpratt want to go hog-wild on the APIs and such? It might be good to update the README.md to reflect the new status as well.

When you're reading, can you prepare a report of what is being published, strategy, vision, etc, and we can send it around for review?

@jhpratt
Copy link
Member

jhpratt commented Sep 30, 2019

I'll update the README now, other things I'll push up at some point; I've already been working on a new Duration struct.

I'll certainly prepare a report detailing what was changed and a migration guide once I think a v0.2 is ready.

@jhpratt jhpratt added the v0.1 label Oct 1, 2019
@KodrAus
Copy link

KodrAus commented Oct 18, 2019

Hey @jhpratt! 👋

It looks like you’ve been pretty busy already on modernizing time. Thanks again for taking that on! ❤️

Is there anything you need or would like any input on at this stage?

@jhpratt
Copy link
Member

jhpratt commented Oct 18, 2019

@KodrAus No problem! I decided pretty early on to do a full rewrite, since not much would carry over.

I don't think there's anything in particular — I'm just starting work on the parser. Feel free to take a look through things, pretty much everything is documented here, which is kept up-to-date with master via CI. There's also a couple hundred doctests.

After I'm done with parsing, I'm going to add #[inline] as appropriate, then verify the correctness of implementations and documentation. Once that is done, I'll pass it off for a full review by you and Alex, then r/Rust and TWIR.

@KodrAus
Copy link

KodrAus commented Oct 20, 2019

That sounds good! It might be helpful to write up sometime about the broader vision you’ve got in mind for time, its API, what you think is in/out of scope, that sort of thing. What do you think?

@jhpratt
Copy link
Member

jhpratt commented Oct 20, 2019

Can do. I had thought about that somewhat already, and determined that nothing should depend on the local system offset, such that outputs will be identical no matter the system's settings. Other things I'll definitely think about more.

@bluenote10
Copy link

bluenote10 commented Nov 9, 2019

Does this deprecation include std::time::Instant, or where exactly will it be in the future? This answer mentions that std::time is superseded by either the time or the chrono crates. However:

  • The time crate seems to be missing std::time::Instant.
  • The chrono crate documentation mentions:

For more abstract moment-in-time tracking such as internal timekeeping that is unconcerned with timezones, consider time::SystemTime, which tracks your system clock, or time::Instant, which is an opaque but monotonically-increasing representation of a moment in time.

and links back to std::time for these purposes.

It would be nice to clarify these points in the Benchmarking programs in Rust Q/A, which currently has contradicting information and at the moment there is no definite answer to "how to measure time in Rust".

@jhpratt
Copy link
Member

jhpratt commented Nov 10, 2019

@bluenote10 I think you're confusing the time crate and the time module in the standard library. The latter is going nowhere, which is where std::time::Instant is defined. The crate is being rewritten by myself, and will contain a thin wrapper around std::time::Instant that allows for some new functionality.

If you're looking for the source code for std::time, check out this page. For the documentation, check out this page.

@bluenote10
Copy link

Indeed, since the issue begins with

The repo lives under the rust-lang-deprecated organisation.

I was assuming this might have been std::time in the past. Thanks for clarifying!

@jhpratt
Copy link
Member

jhpratt commented Nov 10, 2019

Yeah, it used to until a little while ago! From what I can see from both release notes and seemingly shared code, the 0.1 implementation of this crate actually predates (and influenced) the standard library's implementation. Instant didn't come around for quite a while, apparently.

@jhpratt
Copy link
Member

jhpratt commented Nov 14, 2019

@alexcrichton @KodrAus

Would either or both of you care to take a look at the master branch? I believe the API and implementations are sound after quickly checking things over myself. The only item I still want to work on before a possible release is increasing test coverage, specifically on parsing and formatting.

Documentation is available at time-rs.github.io, and there are quasi-short links as well (like time-rs.github.io/Duration) that will automatically redirect to the appropriate struct, enum, etc.

No rush on anything, my goal is to release this alongside rust 1.40, such that I can use #[non_exhaustive] where appropriate. (update: master now requires beta to run)

If you have any questions or concerns, let me know!

@alexcrichton
Copy link

While not exactly a thorough evaluation by any means, a quick once-over and it looks like a great crate! I'm not personally too privvy to all the design intricacies of a "good time library" so I can't really review much on the technical side, but API-wise seems like a good crate to use :)

@KodrAus
Copy link

KodrAus commented Nov 20, 2019

Hi @jhpratt! That's exciting news! 🎉

I'll make time to give this a review over the next week (just got a few other things to get off the stack first).

@jhpratt
Copy link
Member

jhpratt commented Nov 20, 2019

Sounds good! I was going to create a feedback issue in anticipation of community feedback as well. I'll hold off on submitting to TWIR until next week.

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

Successfully merging a pull request may close this issue.

7 participants