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

[est31]

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]

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]

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]

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

[jhpratt]

@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]

@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]

👍 !!

[jhpratt]

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]

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

[alexcrichton]

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]

@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]

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]

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]

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]

That's roughly what I was thinking yeah

[jhpratt]

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]

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]

@alexcrichton Sounds good to me.

[alexcrichton]

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

[jhpratt]

Done. Organization is rust-lang-community.

[alexcrichton]

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]

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

[alexcrichton]

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]

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.

[KodrAus]

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]

@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]

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]

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]

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]

@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]

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]

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]

@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]

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]

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]

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.