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

Unpin time-rs version #246

Closed
mzabaluev opened this issue Dec 7, 2021 · 8 comments
Closed

Unpin time-rs version #246

mzabaluev opened this issue Dec 7, 2021 · 8 comments

Comments

@mzabaluev
Copy link

mzabaluev commented Dec 7, 2021

The pin for time =0.3.2, while helping you keep consistency on MSRV, unfortunately gets in the way of other crates that would like to depend on time ^0.3.5 for checked_add/checked_sub (which should really be used everywhere in preference over the panicky overloaded operators), but don't care that much about keeping their MSRV back.

@mzabaluev
Copy link
Author

Besides, is there a good reason to keep both time 0.3.x and chrono in the dependency tree?

@bradfier
Copy link
Collaborator

bradfier commented Dec 8, 2021

chrono is used in tiny-http, pretty much entirely to parse and emit timestamps in RFC1123 format:

https://github.com/tiny-http/tiny-http/blob/d8e065fab3e231c2b02d552b680a8e702982bd6c/src/common.rs#L398-L414

I'd accept either a PR or even a concrete suggestion for simplifying these uses. Should time be preferred over chrono, the inverse? Both would be suitable for the parse / emit workload and since we don't expose the types directly in the API it should be a minor change.

@mzabaluev
Copy link
Author

Should time be preferred over chrono, the inverse?

That depends on your usage of course, but I find chrono's treatment of leap seconds to be troublesome.

@mzabaluev
Copy link
Author

chrono is used in tiny-http, pretty much entirely to parse and emit timestamps in RFC1123 format

Right; time does not provide that out of the box, and I don't know if it can be easily supported by the format description syntax in time.

@mzabaluev
Copy link
Author

Regarding the pinning issue though, would it be OK to bump this crate's MSRV to 1.51 and unpin time, and at what release would that be made available?

@bradfier
Copy link
Collaborator

Regarding the pinning issue though, would it be OK to bump this crate's MSRV to 1.51 and unpin time, and at what release would that be made available?

This would be acceptable I think, I need to cut a release to respond to the Brotli vulnerability anyway so I can roll this change into that release.

@bradfier
Copy link
Collaborator

@mzabaluev this is complete and released as v3.5.0 34d3134.

@bradfier
Copy link
Collaborator

(Or rather, it will be, once crates.io stops 503ing when you try and publish a release.)

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