This crates needs to be archived, and should redirect to web-time

[erwanvivien]

• Unmaintained
  • Bug in implementation not fixed for almost a year SystemTime::elapsed() is broken #49
• Is slow to use Performance Cache the performance object #21
• More here:
  • Make WASM polyfilled Instant work in web workers. rust-cv/cv#75 (comment)

Alternative is to change to web-time

[djc]

@sebcrozet do you think think it might make sense to put out an informational advisory to make it clear this crate is no longer being maintained? Would be nice to inform downstream users.

[TheMartianObserver]

@djc Given the extensive use of this crate (per stats on crates.io) and the lack of maintenance, seems prudent to submit this crate to Rustsec's database as unmaintained (certainly meets the Unmaintained Crate policy timeline thresholds).

@sebcrozet Please let us know if you plan to continue maintenance! Will likely submit this in the next week or so.

[sebcrozet]

@TheMartianObserver I don’t expect to have much time maintaining this crate unfortunately. So I am happy to provide maintenance access to a volunteer. I am otherwise OK with marking this as unmaintained.

[TheMartianObserver]

@TheMartianObserver I don’t expect to have much time maintaining this crate unfortunately. So I am happy to provide maintenance access to a volunteer. I am otherwise OK with marking this as unmaintained.

Thank you for the response, and completely understand about the time commitment.

Unfortunately, given that time-web exists with effectively the same API and a number of other crates have already shifted to that, I think it's probably best to archive this repo and mark it as unmaintained.

[Captainfl4me]

The main problem with web_time is that is does not support wasm32-unknown-emscripten target. Any known solutions ?

[sebcrozet]

I marked the crate as unmaintained on the readme and cargo badge.

[erwanvivien]

Thanks for the good work seb 🙏

[daxpedda]

The main problem with web_time is that is does not support wasm32-unknown-emscripten target. Any known solutions ?

AFAIK wasm32-unknown-emscripten doesn't need a polyfill, Std should work just fine. Therefore web-time, which in this case just re-exports Std, should work as well.

EDIT: Nope, I was wrong, wasm32-unknown-emscriptens Std implementation of time panics as well. I'm looking into if this in scope for web-time.

EDIT 2: My bad, I forgot that Emscripten falls under cfg(unix). Just tried it as well, Std works just fine, therefore web-time works as well.

[madsmtm]

I've submitted an informational advisory to the database in rustsec/advisory-db#2056.

Another thing to do would be to add something like #![deprecated = "use the `web-time` crate instead"], that'd probably be more successful in getting people migrated.

A final option would be to release v0.2 as just pub use web_time::*;, that'd at least avoid people having updated dependencies.

These are not mutually exclusive.

[hrxi]

Another thing to do would be to add something like #![deprecated = "use the `web-time` crate instead"], that'd probably be more successful in getting people migrated.

Why is that necessary? There's no security vulnerability in this crate, is there? Anyone who uses it can continue to do so, unless they hit a bug and will come to this issue tracker and see that it's unmaintained.

[madsmtm]

Another thing to do would be to add something like #![deprecated = "use the `web-time` crate instead"], that'd probably be more successful in getting people migrated.

Why is that necessary? There's no security vulnerability in this crate, is there? Anyone who uses it can continue to do so, unless they hit a bug and will come to this issue tracker and see that it's unmaintained.

It's not necessary, just a nicety, hence why I didn't open a new issue for it.

[hrxi]

Sorry, i meant: Why is it necessary (or desirable) to make people migrate? That mostly causes busy work and if this crate works well for them, why should you create busy work?

[madsmtm]

I hope we can agree in general that it's desirable to get people to move to maintained alternatives, even when no current security issues exist?

In this particular case, I agree that it's not really an issue (yet, at least, though it might be once wasm-bindgen releases the next breaking version), the crate is fairly small.
I'm more in favour of other option anyhow (releasing a new version with pub use web_time::*;).

[hrxi]

I hope we can agree in general that it's desirable to get people to move to maintained alternatives

Not really. In the case of a feature-complete crate with no bugs that affect you, it's very sensible to not take the churn to switch to new dependencies every time a crate becomes unmaintained.